Session Date/Time: 21 Jul 2026 09:00
[00:00:06] Alexey Melnikov: Ready? Welcome to mailmaint at IETF 126 in Vienna. Please note, as Barry likes to say, note the note well well. This slide contains a number of documents and things we are expecting everyone here to be familiar with and to observe when participating. This is the code of conduct. This is standards processes, working group procedures, intellectual property. Please be familiar with all of it. All of it applies to everyone here and on the mailing lists. If you have any questions about any of that, please see your area directors or the working group chairs. Meeting tips, please use the Meetecho or Meetecho Lite if you're in the room. Keep your audio and video off if you're not if you're not using the on-site version. Use your hand to queue the recording stuff, and the transcription stuff works best if people are actually participating in the queue. We will be managing it through here. Use of a headset if you're remote is strongly recommended, and please state your name each time you'd be in speaking even though if if we're following the process, the names will be automatically tagged. A few useful links. The the meeting agenda for the whole meeting is available on the data tracker. Other part Meetecho and other preparation links on the on the middle, and you can get the slide deck from the data tracker as well. If And you need to report any meeting issues, there's a URL where they can be reported. But it sounds like the audio is okay in the room, and temperature actually seems to be okay too. Our agenda, five minutes for administrivia, which we are in the process of doing. Five up five minutes on completed documents and other status updates, and then we'll be discussing active drafts for the remainder of the time that we have. Any agenda bashing before we before we continue? It's a pretty thorough agenda. I'd be amazed to see if there are changes to make. OAuth profile, Ricardo, do you have do you have slides for this or you're just getting up? No. I'm sorry.
[00:02:00] Barry Leiba: Actually Can
[00:02:00] Alexey Melnikov: I jump on something?
[00:02:01] Barry Leiba: Yeah. For for so, Brian, would you mind taking minutes? Oh, sorry.
[00:02:05] Bron Gondwana: I can get in. That's not learning.
[00:02:09] Alexey Melnikov: Is it? He's having problems too.
[00:02:10] Barry Leiba: Yeah. I'm having issues too.
[00:02:12] Bron Gondwana: Thank you.
[00:02:14] Daniel Kahn Gillmor: Let me grab a
[00:02:15] Speaker 4: pen and
[00:02:15] Arnt Gulbrandsen: pop up.
[00:02:20] Barry Leiba: As as far as the OAuth spec and the PAC spec goes, there were some interrupt testing during the hackathon. We've got two clients talking to two servers with the current specs. Aaron Parecki did a review of the OS spec last night, which Neil responded to. I don't know if Neil is online and has anything he wants to say further.
[00:02:45] Alexey Melnikov: Neil is not currently online.
[00:02:49] Barry Leiba: Anybody who was at the Interop have anything that they wanna say? You you do wanna say something? Yeah.
[00:02:58] Alexey Melnikov: Is Mike back
[00:02:59] Barry Leiba: there, Mike?
[00:02:59] Alexey Melnikov: Please do.
[00:03:00] Ben Bucksch: Just jump in. Yeah.
[00:03:01] Alexey Melnikov: Yep. Hop on the way.
[00:03:07] Aaron Parecki: Yeah. Hi. Aaron Parecki. I looked over the OAuth profile last night, sent a bunch of notes to the list. Neil responded. So helpful context. I think my biggest note was about the use of dynamic client registration. I I think I mentioned this, like, a year and a half ago or so when I was first taking a look at this. Still concerned about it, but I understand the constraints you're working with and the considerations. So I'm crossing my fingers it works out. I'm a little I'm still con I'm still concerned. I'm hoping to pull in some other folks to give some background on that as well from their perspective. But, yeah, the other other things were relatively minor notes. Looks like Neil's gonna make some minor edits to the to the doc space on that, so all generally good. But,
[00:04:07] Alexey Melnikov: yeah,
[00:04:09] Ben Bucksch: thanks for that.
[00:04:10] Barry Leiba: Sounds good. Thank you for the review. Appreciate it. I guess we'll continue to work on this on the list.
[00:04:16] Alexey Melnikov: Anything else this one? Okay. Auto config. I'll drive your slides then.
[00:04:29] Ben Bucksch: We've got seven, actually.
[00:04:31] Speaker 8: Let see if I can
[00:04:32] Alexey Melnikov: give you control over the slides here. So
[00:04:41] Ben Bucksch: this is a little update about the autoconfig draft. That's shortly because not everybody some might know this, so I'm going to be brief. But some of you might not know what this is, autoconfig, allows you to when you set up your email client, you enter your email address. It goes to a URL, well known URL, like this. There's multiple ways. And you get back a description of what the email sir the IMAP server, SMTP server, etcetera is, what the email what the login name is, whether it's SSL on auth which authentication method. There's a way in the file to also return the OAuth server. So I have the authentication URL in there, token URL. I have this scope in there that can be directly returned. And this the conflict can contain directly the client ID that I'm supposed to use for this use case. So that sidesteps the issue that Aaron mentioned with the client the client registration. This is by surprise provided by the by the provider or somebody else. It can also express more than email because often nowadays we have single sign on with multiple different services. It can express CalDAV, WebDAV, a chat, Matrix, XMPP, even your video conference servers. So if you have an integrated client, you can get all these services at once with a single setup. And Yeah.
[00:06:18] Alexey Melnikov: If if Aaron's in the queue. Do you wanna cover do you wanna take questions at the end or at the three as they go?
[00:06:24] Aaron Parecki: Go ahead.
[00:06:25] Alexey Melnikov: Aaron.
[00:06:29] Aaron Parecki: Yeah. Hi, Aaron. Correct me. I do have a question about that OAuth one here. Makes me a little bit nervous duplicating some of the OAuth metadata here. Particularly, the authorization endpoint and token endpoint can be derived from the issuer if the OAuth server supports the OAuth server metadata.
[00:06:46] Speaker 8: Mhmm.
[00:06:46] Aaron Parecki: So it might be simpler to just say, here's the issuer URL and have the client go and actually follow the OAuth breadcrumbs to get the two endpoints so that you're not duplicating that so that it doesn't get out of sync here.
[00:07:01] Barry Leiba: Mhmm.
[00:07:01] Ben Bucksch: It's a deduplication, but not simpler because, yeah, I can take this information directly, and I don't need the issue. I don't need to take another URL and re to query another URL to get this information and pull it out of some JSON. I have the information directly, and it's just the two URLs. This is a trade off. I mean, if this if you people feel strongly about this, this can be discussed. But Or it isn't here. The the idea of this document is you have everything you need to directly contact the IMAP server and authenticate there. You don't need any other things from anything else. You don't need to make any other lookups. That's the idea. And and just this information is sufficient. But like I said, I'm I'm not really strong on this point. Is it okay? It's open to
[00:07:45] Alexey Melnikov: Aaron Aaron, is there something that you want think needs to change here? Because we've last called this once already. Speak. Speak to speak. You think it's fine the way it is?
[00:07:56] Bron Gondwana: You're You're okay with us sending this to the IES team to
[00:07:58] Alexey Melnikov: take it?
[00:07:58] Ben Bucksch: Thank you. Speak to yourself.
[00:08:00] Aaron Parecki: I mean, the the the the the change would be to remove just the two authorization endpoint and token endpoint and then use the OAuth server metadata instead to do that discovery, which, yes, adds a request. The but the the other two values make sense in this context because they're not things that are server metadata. They are things about this particular profile. So the, like, the scope and the client ID do make sense here in the context, but it's a trade off. I guess the other consideration would be, like, if there's any future things that need to get discovered, you're gonna have to add them to this document versus having it built into the discovery mechanism by using the lost server metadata. So that's that's again, that's the trade off there is, like, there are other properties on a server that are that are potentially relevant that are already built into the OS server metadata document. So if you ever needed a client to be aware of those, you're going to have to do the extra step of adding them to this XML document as well or just tell it to go fetch the metadata anyway. So it's a trade off. I understand the
[00:09:16] Ben Bucksch: the Question. Because you probably you know best. You're saying OAuth metadata. I'm assuming this is a well known URL that is on this. Can I rely on this on 100% all OAuth servers no matter what implementation? They all have that without exception.
[00:09:33] Aaron Parecki: No. No. So it's a it's a well established extension. It's not part of the core OAuth spec. So it is widely implemented, but it's not necessarily everywhere.
[00:09:44] Ben Bucksch: I would need data on that because the trade off is just really these two URLs. So if this adds instability because some servers don't have it, I'd rather have them in here. But if you have hard data that you say, okay. All the servers that are relevant have it. Right?
[00:10:02] Aaron Parecki: Yeah. It's it's likely that most of the relevant servers would have it. Can't promise all.
[00:10:08] Barry Leiba: Right. Yes.
[00:10:10] Ben Bucksch: Okay. Well So it's a it's
[00:10:11] Aaron Parecki: a it's a trade off.
[00:10:12] Ben Bucksch: Details we can discuss on the it's it's a fair point. Yeah. We can discuss the details. We we need more data in order to make a decision.
[00:10:18] Aaron Parecki: The other thing I would say is if you do end up going with this route, it would be worth calling this out explicitly as a decision that Okay. You are not relying on the loss of metadata for these particular reasons Okay. Just so that nobody comes back with the same
[00:10:34] Ben Bucksch: Fair enough.
[00:10:34] Aaron Parecki: Question later.
[00:10:36] Alexey Melnikov: Fair enough. Thank you. I'm certain we get it.
[00:10:40] Ben Bucksch: Alright. So we covered
[00:10:41] Alexey Melnikov: You got two more. Yes. Sorry.
[00:10:43] Ben Bucksch: Oh, sorry.
[00:10:44] Alexey Melnikov: Neil.
[00:10:47] Ben Bucksch: Oh, this is a hot topic.
[00:10:49] Alexey Melnikov: I'll wait.
[00:10:50] Neil Jenkins: I'm slightly confused, Ben, that you're saying it was open for, like, to change because I thought the point of this document was an informational document specifying what was already implemented, which is, you know, why this is we've got two documents going. This is what?
[00:11:07] Ben Bucksch: This is implemented.
[00:11:07] Neil Jenkins: Yes. I know. But then you were saying open to change. Because, I mean, this is wildly insecure, is why we're not using this for the standards one. Because, you know, you for example, you could put a a legitimate login.example.com and attacker's token URL, and they're gonna send you all of them. You you're gonna do the whole exchange then send to the, code exchange straight over to the attacker, which is, you know, why you have things like checking the issue all the way through and various other things in the in the met in in in the standards. So I don't know. If if this is open to change, then why, I guess, is is almost my question on that.
[00:11:44] Ben Bucksch: So first, can you be more careful with words like wildly insecure? Because if you change the issue here, you have the same issue. If you don't use OAuth and you have the password authentication, you have the same issue, so that doesn't introduce any new insecurity. I didn't understand not
[00:12:00] Neil Jenkins: not true at all. There's lots of very careful consideration you you as you read the
[00:12:05] Ben Bucksch: I didn't understand your actual question.
[00:12:09] Neil Jenkins: Well, the question was, is this documenting something, you know, as an informational document that's
[00:12:15] Ben Bucksch: I'm trying
[00:12:16] Barry Leiba: to But then
[00:12:16] Neil Jenkins: if it is, why is it open for change? Why are you saying let's take that for discussion? Those seem incompatible things.
[00:12:25] Ben Bucksch: Okay. Sorry. I didn't sleep enough. I tried to work with you. I was trying to be working with Aaron here. I have to think this through. Sorry. I've been put on the spot. That's fine. Don't nail me down on
[00:12:40] Alexey Melnikov: That's alright. It's it's feedback that
[00:12:42] Barry Leiba: you take to the document.
[00:12:44] Ben Bucksch: There's another button in the queue.
[00:12:45] Alexey Melnikov: No. It's left. He left the queue. Okay. Thank you. Thank you.
[00:12:48] Ben Bucksch: Keep going. So Neil was asking about deployment. There's 10 different email clients that implement that to different degrees. Not everybody implements everything that I just showed. Thunderbird, Evolution, Parula, and many others implement this. Fifth a survey 50 that I found randomly by searching this because I we did our own survey, and but I don't have the data with me. I forgot it. 50,007 domains have this deployed, which is about 8.5% of all domains with emails with an MX server have this particular method deployed. That's more than auto discover exchange auto discover. I was actually surprised about that. When I created that, I didn't think that it would happen. It helps 100,000 users per day just for Thunderbird alone, which is about fifty million hours of work saved in searching configurations. So this is just to show that it's useful and act actively used and actively helping. So now to the actual content of this of this talk. What is the current status of this document? Murray made a very thorough review a while ago. I addressed almost all his points. He did a re review, which I still have to read address, but I think most of this is addressed. A very common request was to have a formal description of the XML. So I did this with relax n g. There's a whole relax n g at the end and an appendix. And then in each section, you have a little snippet of the relax n g, which whatever section describes it is is a snippet in there in addition to an example. If you prefer the example, you read this. The authentication was made clearer where this what authentication method comes from, differentiation between HTTP and the Sassle methods, and I improved the intro based on Murray's feedback. So that's the revisions that happened recently. That's the zero six as the newest. What's still to do? Murray just yesterday made a review. I have to go through this. Last night, from from Thunderbird also sent me privately some very detailed review. I have to go through that. He had very, very good points, which I need to address. It needs some final proofreading, but then then there's one big outstanding issue. And then, yeah, then I'm out of task to do work on this, and then it's back to you guys. There's one outstanding issue. This uses autoconfig.example.com, which is not what the well known URL is supposed to be. The thing is this was designed 2008, and the well known RC came out in 2010. So the question is right now, is this a violation or can this be grandfathered in? And because it's describing a active deployment, then we cannot change those deployment. There's nothing we can do about this. So Murray is on this. He's trying to sort this out and what we can do about this. The only thing that I can see that we could do, we could market deprecate it and do a new method based on DNS server and say this is a new method, and the old one is deprecated but still in deployment. This is some compromise that I could see.
[00:16:26] Alexey Melnikov: Yeah. That's it. That's it. Any questions on his slides? I don't mind going through the feedback that I the outstanding points that I've got. I've got a separate slide deck for that. If we have another half an hour or twenty minutes for this topic, something like that. So I can go through them quickly. That way, you don't have any questions about well, what we can sort all that out, like, right now. No. Okay. Aaron's back
[00:16:48] Speaker 8: in the queue.
[00:16:49] Alexey Melnikov: Go ahead, Aaron. Sorry. I I gotta
[00:16:51] Daniel Kahn Gillmor: get back here and check-in the queue.
[00:16:53] Aaron Parecki: Yeah. Hi, Aaron. Did just skim through the other doc again. So there's a there's a couple of dots to connect here. So in the in this document, it says that you should follow the OAuth profile for public clients if you've got that OAuth config.
[00:17:11] Ben Bucksch: The second part of it. Yeah.
[00:17:12] Aaron Parecki: In that document, it actually is a requirement to fetch the OAuth server metadata from the issuer
[00:17:19] Ben Bucksch: you want. And that's why the spec says only the second part of it. That says, okay. Take take the issuer, go and take the data from there, then do a demand and client registration, do that, and then you do all the other things. And what this document is referring to is all the other things that the public all the public client specifies. Like, it says, you have to have a certain you cannot lock people out after eight hours and all these kind of other things that it specifies. But these two first steps, you can completely sidestep. It's And yeah. That's just Okay.
[00:17:50] Aaron Parecki: Okay. Just wanna make sure that's not in conflict because I didn't Maybe I need
[00:17:55] Ben Bucksch: to be clearer on which steps.
[00:17:57] Aaron Parecki: Because I didn't notice the second only part two thing in that doc.
[00:18:01] Daniel Kahn Gillmor: Okay.
[00:18:02] Alexey Melnikov: I have next, and then we'll go to.
[00:18:13] Bron Gondwana: Hey, Ben. Yeah. Basically, what I told you offline that I believe this working group should should work in just one autoconfig specification, which I believe it should be PAC. I know you are not happy with some parts of of pack, but I think we should work toward adding that to pack rather than having two competing specification for the same thing. Yeah. That is my my point of view.
[00:18:42] Alexey Melnikov: My impression is that we decided a while ago that we're gonna publish autoconfig to describe what has been done up to this point, and then pack is the standard going forward. That's why this document is informational. That one's proposed standard. Ah, okay. So is there are we are not are we reopening that debate, or are we still all okay with that?
[00:18:59] Bron Gondwana: No. No. I was not aware of it.
[00:19:01] Aaron Parecki: Sorry. Yeah.
[00:19:02] Bron Gondwana: That makes sense then. Okay. So but you wanted to add some JMAP stuff also. So if not, you're adding new stuff to what was already there in the deployed. Right?
[00:19:12] Ben Bucksch: Well, the JMAP stuff is is in there. It's in in it's in use. Okay. My client right now, when my client talks to your server, it doesn't work because I don't get the JMAP information. So Yeah. Yeah. That is that is an active use, and it doesn't work right now.
[00:19:29] Bron Gondwana: Yeah. That was the last draft back then. But okay. Yeah. Yeah. It's fine if it's stating for my information. Yeah.
[00:19:36] Alexey Melnikov: I should add that if if the document that he's got doesn't make it clear that this is documenting old and getting referred to PAC saying that's the new way to do things, then we should add that text if it's not there. Just so that just so that someone else is gonna have the same question that you have.
[00:19:50] Ben Bucksch: Yeah. Okay. Sure. Just just something else to add to this. It's not that I disagree with PAC. It's just they cover different things. PAC is describing how an Internet provider should do things, and autoconfig tries to describe how the inter config Internet providers are. It tries to describe the status quo not only in the document, but also in the deployment. So this can also describe Google and smaller deployments, which have not been able to adapt to PAC. So they they it's a little bit of overlap between the two, but it's mostly what Maria said. Yeah. Okay.
[00:20:23] Aaron Parecki: Yeah. Okay,
[00:20:24] Alexey Melnikov: Art.
[00:20:25] Arnt Gulbrandsen: Right. I appear to have technical problems. Can't log in, but
[00:20:29] Ben Bucksch: We have not only you. Yeah.
[00:20:31] Arnt Gulbrandsen: Not only me. I'm glad to hear that. Question about marking this deprecated and provide marking autoconfig dot deprecated and providing you an alternative, I tend to lean towards describing what the code did up to yesterday. Is there appetite among existing deployments for changing to a new recommendation? If the answer is either no or uncertain, then I would say let's not mark anything deprecated. Let's just say this is informational. It describes what cPanel did up yesterday and just publish and let it go.
[00:21:26] Ben Bucksch: That would be my preference. But if that that's just a peace offering, like, if other people disagree very strongly with this, that would be a way to maybe to compromise to go forward.
[00:21:37] Arnt Gulbrandsen: Makes sense. Do you you know about implementation status? Is their appetite would, for example, Thunderbird actually update this to look for something else? Would cPanel update this to publish dot well known instead of autoconfig?
[00:21:56] Ben Bucksch: I cannot speak about those particular ones, but I have seen a few people request support for DNS server.
[00:22:06] Arnt Gulbrandsen: Request support. Yes. But we can do that. Anyway, my default is to just describe what is their up to yesterday.
[00:22:17] Barry Leiba: Thanks.
[00:22:18] Ben Bucksch: Ricardo.
[00:22:20] Ricardo Signes: Hey, Ricardo. It's Signes. Yeah. I'm not too concerned about whether we market deprecated or not. I think that in the end, we're going to have to have a security considerations section. Mhmm. And that's gonna point out a number of problems. I think the the point of you can use this to document Google's standard, for example, that does give the client information. But if Google's not publishing this information from their own authoritative source and we are letting the document control things like the token refresh URLs, This this is where we start talking about significant security considerations. You've given a whole lot of information to the client about how to configure from a source that you hope is trustworthy, but it's not the authoritative source. That's gonna end up in security configure security considerations where it belongs.
[00:23:01] Alexey Melnikov: Mhmm.
[00:23:01] Ricardo Signes: And at that point, I think we're gonna be able to say, like, clearly, we either do or do not need a header on this saying, this is historical. Maybe don't do it anymore. Or we're gonna say, anybody who's reading this is gonna read security considerations and understand how to move forward with it. But yeah. I mean, obviously, I'm on I'm on the side of new standard for moving this forward in a new way. But as for this document, I think we'll be fine pointing out what the words are.
[00:23:27] Ben Bucksch: There there's already a big section for security configurations. There's also a big section for alternatives rejected. Your specific question about Google, the way this currently works is that the client itself has a database that it trusts and that is manually maintained. So Thunderbird manually maintains a database and says, this is the server for Google. Use this. And Thunderbird makes the secure TLS secure channel. Same my client does the same thing. And and this part is optional in the document. So this is basically and and most clients already do that in one way or another. So this is basically describing what clients do. Absolutely. Yeah. Independent of the spec. Like, if the spec is not there, they're doing it. E EM client does that in its own way. And Yep. So it sounds like not a new security problem.
[00:24:17] Alexey Melnikov: It sounds like when we do another working your blast call, which is probably gonna be appropriate given the number of changes that have happened since the previous one, I'll be looking to you and Aaron in particular, maybe Neil, for make sure the security considerations is complete. It doesn't need to be a bulletproof protocol. Whatever we send to the ISG has to be thorough. That's all. Thanks. Do you wanna go through my issues real quick?
[00:24:40] Ben Bucksch: In in the open room?
[00:24:42] Barry Leiba: Yeah. If you like. I
[00:24:44] Alexey Melnikov: how do I stop doing slides?
[00:24:46] Barry Leiba: You you gotta unshare and then reshare.
[00:24:47] Alexey Melnikov: Oh, because I've still he's got the clicker. Gotta tell him. Stop slides. Change slide. It because of the network problems, it can't do mine. Alright. I'll just have to talk about them.
[00:25:02] Robert Stepanek: Mine.
[00:25:03] Alexey Melnikov: What's that? I'll do interpretive dance. There's in three I've sent all these to the list, but I wanted to go through them really quickly just so that we know what their the few remaining issues are. There's a place where you say the email provider element has no semantic purpose and exists for legacy reasons only, but its content is significant. I don't know how those two things can be true at the same time.
[00:25:25] Ben Bucksch: That was just bad wording. Okay. What I mean is the the element itself like, this tag doesn't mean anything, but the content. Like, imagine this tag is not there, but the content is there, basically. This is just to address some feedback by saying, why is this email provider in there? But it's can I can also strike it? It's
[00:25:42] Speaker 4: just Oh,
[00:25:43] Alexey Melnikov: okay. Okay.
[00:25:46] Ben Bucksch: Just wording.
[00:25:47] Alexey Melnikov: The very the very minor point, but the you have a in section three one, there's a giant XML example. I think that should be an an appendix just because it's much more common in my experience to have us you do all the formal stuff, and then you'd present what it would look like if you put it all together. It's not a major thing. I don't mind sending it the way it is, but that was just it it read funny to me.
[00:26:08] Ben Bucksch: Can can I speak to this? Sure. I feel rather strongly about this because when I read documents, I have trouble when there's all first and foremost syntax and then the example because I need to see the example to understand the formal syntax because this gives me the overview. So it makes for me the documents far easier to read if I have a complete example first. Mhmm. And then I can have a at least a rough picture of what I'm talking about.
[00:26:31] Bron Gondwana: Right.
[00:26:32] Ben Bucksch: And if I have this in the appendix, it makes the document for me much less reasonable. And I got feedback from others that they like this, that there's a big example, and that that makes it easier to read.
[00:26:41] Alexey Melnikov: Okay. I mean, it's not a major point, and the the important thing is that we send whatever, like, has consensus to go ahead. So I'll just leave it for you and the working group to talk about. In display name and display short name, you have it should be no longer than 30, must be no longer than 60, and the number and then another one should be no longer than 12, must not be longer than 20. Where do those numbers come from?
[00:27:00] Ben Bucksch: In the the in the next two paragraphs
[00:27:03] Arnt Gulbrandsen: is the description
[00:27:04] Barry Leiba: Uh-huh.
[00:27:04] Ben Bucksch: What the client is going to do with it.
[00:27:06] Alexey Melnikov: Why but where does 30 come from? I understand what it's used for. Why is it why is 30? 30 is an interesting number to sort of run into right now.
[00:27:13] Ben Bucksch: And you can also make a 32, but it needs to be how need to limit it to display. You cannot make one at 26 characters in the place where I show the account. Okay.
[00:27:23] Alexey Melnikov: That's it's a rendering problem.
[00:27:25] Ben Bucksch: Material limit, but it needs to be somehow short, and I'm trying to nail down what I mean with short, basically.
[00:27:31] Barry Leiba: Okay.
[00:27:31] Ben Bucksch: It's it's a
[00:27:32] Alexey Melnikov: Okay. I I'm trying to anticipate questions will get downstream. Like, why did you pick this? Why didn't you pick something else? It's just to You you can programmers with, like, a You decide how you want to explain it. It seems like they're a bunch of unexplained numbers. That's all. The I this there's this problem with that I've always had with shoulds when you don't explain why every time you present a should to somebody, you're giving them a choice to implement, and you want that to be an educated choice that they're they're whoever's your implementer is gonna pick one or the other. And so why don't if you don't present them with information, they'll think, well, why do I have to bother with this? I can just do the anti of the should and get away with doing less work. So if you wanna encourage them to it, you have to explain why this is the right thing to do. But there are several shoulds that just are like, you should do this and it wanders on to the next thing. So I've I've highlighted where those are.
[00:28:17] Ben Bucksch: Can can I talk about that? Sure. Because you're the experts on this. Obviously, this is new for me. Yep. But reading the document about explaining this, my understanding of should is you really it's basically a must Mhmm. But you can derivate if you have a good reason for it.
[00:28:32] Alexey Melnikov: I don't You need to explain. I don't want to.
[00:28:33] Ben Bucksch: You need yeah. That's not a good read. Right. You need to have a good reason. So, basically, I'm using must only for cases where either my client is going to break if you do it in a different way for interoperability Mhmm. Or if there's a security problem.
[00:28:46] Alexey Melnikov: Right.
[00:28:47] Ben Bucksch: Otherwise, if if there's not one of the two Right. Using should for everything else.
[00:28:50] Alexey Melnikov: That's the answer, though. It's like you have to do this or else this is the consequence of you not doing it. Here comes Pete.
[00:28:59] Pete Resnick: You this is Pete. You you are correct that should means must unless you have a good reason. But should means you must do this because it will break something or because it will fail interoperability unless you have a good reason. So should doesn't mean I think it would be a really good idea. So these numbers strike me as being it would probably be good to keep it under 30 because such and so, but not it should be under 30 or it should be 30 or it should be 32. Mhmm. Because what you're saying by saying it should be 30 is if you go over 30, there's gonna be a real problem that justifies a must. Yep. But I can think of cases where you wouldn't wanna do that because you're in a closed environment, because you know that the screens are gonna be tremendously big in your environment, and it's not a general purpose reason to, you know, to do. So I would get rid of the shoulds in this case if your purpose was to say, there's lots of cases where it would be really nice if you kept it to such and so. Just say
[00:30:15] Ben Bucksch: So so may
[00:30:15] Pete Resnick: It it would be good to keep it to such and so because there are tiny devices that can't fix things and get rid of all the shoulding.
[00:30:24] Ben Bucksch: So then I misunderstood you. So I thought you meant I should upgrade the should to a must, but what you mean is you should get rid of the should as a as a term by just
[00:30:33] Alexey Melnikov: Or as normal way of trying to Explain the decision. How would it implement it? What do I need to know in order to pick one side of the shit or the other intelligently?
[00:30:41] Ben Bucksch: I I thought I I'm explaining that because, like, if in the, like, account selector, you cannot have labels as long.
[00:30:47] Alexey Melnikov: Well, this is I'm actually talking about the XML validation section.
[00:30:50] Ben Bucksch: I see.
[00:30:50] Alexey Melnikov: So you'll see it you'll see it in the reply. Art?
[00:30:54] Arnt Gulbrandsen: Basically repeating except slightly different. A lot of people who should know better treat must treat should as if it was some sort of gentle suggestion, unless today is a Tuesday.
[00:31:06] Ben Bucksch: Like a red traffic light.
[00:31:10] Arnt Gulbrandsen: Sure. Must or skip it.
[00:31:14] Alexey Melnikov: Right. Yep. Let me jump to well known u r I. There's a couple of other sections where it shoulds. It's in the it's in the email. Let me jump to the well known URIs problem. Just so everybody in the room knows, a document that carves out a specific piece of the of a URL. So you you pick the domain name, that's that's not under your control for this. But the if you what the soon as you get start describing the path, if you force the path to be something, HTTP Directorateectorate jumps all over that, and that that's not our space to claim. Now he's right. This is the the well known structure that is the solution to this in the in the HTTP space came along in 2019. This work started in about 2008. So we're talking about something that has predated the well known construct. HTTP Directorate still wants us to at least pay attention to that to that strong preference that they have. So the compromise that I think I'm hearing from them is you try the well known method. This this specification needs to try the well known method. It won't find anything, but you're supposed to try it. And then you can fall back to the old method to doing it. Right? So that's probably what we're gonna end up sending. They're happy with that? I'm so I'm told. You made John get up.
[00:32:23] John Klensin: So that's
[00:32:24] Barry Leiba: I was actually pointing at
[00:32:24] John Klensin: the list. Sorry.
[00:32:28] Arnt Gulbrandsen: You phrasing, actually.
[00:32:29] Speaker 4: They're they're good with that? I am Mostly, are you all good with that?
[00:32:34] Daniel Kahn Gillmor: Right. No.
[00:32:39] Alexey Melnikov: I I will send through send to the ISG whatever we decide as consensus, but, apparently, we can expect a lot of friction on point if we don't do this.
[00:32:47] Speaker 4: I mean, so so we have deployment, that uses the autoconfig. Yep. Okay. So I think that's a that's a good pushback. Right? And we'll just have to have that fight with the HTTP director next.
[00:33:00] Alexey Melnikov: That's where we wanna go. I I was warned yesterday. I wanted to bring it here so you all go in. You're prepared for what's gonna want to happen. I
[00:33:08] Ben Bucksch: know we didn't wanna start a war.
[00:33:10] Alexey Melnikov: I I I don't really care about that so much. I just want a smooth path through the process. So
[00:33:15] Ben Bucksch: You just want a smooth
[00:33:16] Barry Leiba: DKG, you have you have thoughts on this?
[00:33:18] Daniel Kahn Gillmor: Yeah. I just I I wanted to echo what John just said and maybe maybe broaden that out a little bit. It seems like the group is still confused about whether this is a we are documenting what currently exists or we're trying to improve this and and align it with modern thinking and concerns. And the clearer that we can be that this is documenting what already exists, the easier it is to say, hey. Yeah. Of course, if you're writing a new thing, you'd use that well known, but that's not what we're doing here.
[00:33:50] Barry Leiba: Mhmm.
[00:33:51] Daniel Kahn Gillmor: So, you know, if that's not up already upfront, and I apologize I have not read the the recent version of the draft. But if it's not already upfront that this is informational, this is documenting existing practice.
[00:34:01] Ben Bucksch: Yeah.
[00:34:01] Daniel Kahn Gillmor: We're just trying to get the nuances of of what clients currently do, then it needs to be more visible. Because then that's an easy answer for folks to say you should use that well known.
[00:34:12] Alexey Melnikov: I think that's perfectly reasonable. In fact, an appendix that says we are aware of well known. This is documenting blah blah. Like, just call it like, go go right head on at it. I think that's probably the move. This is not the right way. Yeah. Right.
[00:34:24] Ben Bucksch: This is easy to do. Yeah.
[00:34:25] Speaker 4: Design this
[00:34:26] Robert Stepanek: from scratch, we wouldn't have
[00:34:27] Alexey Melnikov: done this. Right. If this is being it's that's exactly it. If this was being designed today, we would go the well known way.
[00:34:34] Ben Bucksch: Happy with adding that.
[00:34:35] Alexey Melnikov: Okay. That's it. That's my list.
[00:34:38] Speaker 4: Okay.
[00:34:39] Daniel Kahn Gillmor: Sorry, Arnt.
[00:34:40] Alexey Melnikov: Did you have something?
[00:34:41] Arnt Gulbrandsen: What you said?
[00:34:42] Alexey Melnikov: Okay. Arnt agrees with me a 100%. Are we done? Yes. Good. You're done. Thank you. We have another topic. Who's next? Art. You did this is your selection. I'll give you the slide clicker. All yours.
[00:35:03] Barry Leiba: No. You
[00:35:03] Alexey Melnikov: need wrong ones. Yeah.
[00:35:04] Bron Gondwana: You need
[00:35:05] Arnt Gulbrandsen: find the
[00:35:05] Speaker 4: right one.
[00:35:06] Alexey Melnikov: I just uploaded the right ones.
[00:35:08] Arnt Gulbrandsen: Hold on. Transparent background Yeah. What things will look like if you have Sorry.
[00:35:14] Alexey Melnikov: I did upload the right deck. I'm sure it's in there somewhere.
[00:35:21] Arnt Gulbrandsen: I discovered this morning that I have software that supports a transparent background. Would you do this?
[00:35:25] Speaker 8: I did not
[00:35:26] Alexey Melnikov: delete the wrong one. No. It's the right one.
[00:35:31] Arnt Gulbrandsen: Syntax instead of address syntax in the data track, if you have
[00:35:33] Alexey Melnikov: Yep. No. It it's not here. Hold on. I have to rejoin the meeting. One second.
[00:35:39] Arnt Gulbrandsen: Anyway, that slide is a lie. There are two drafts, but I'm going to talk about one of them. I want to defer the other one. Can they see that
[00:35:50] Speaker 4: at all?
[00:35:51] Alexey Melnikov: No. No? No.
[00:35:52] Arnt Gulbrandsen: I Barely visible there, not visible here. Yeah.
[00:35:56] Alexey Melnikov: It's like the plenary slides that were all yellow that one year.
[00:36:02] Barry Leiba: If you have them locally. I do have them locally.
[00:36:06] Alexey Melnikov: Oh, I I see. Can you
[00:36:08] Arnt Gulbrandsen: just share the screen? And somebody blessed them, but they're Can I can
[00:36:12] Alexey Melnikov: I share screen correctly?
[00:36:14] Barry Leiba: Think so.
[00:36:17] Alexey Melnikov: Oh, I see. Here.
[00:36:22] Speaker 4: Gonna have to go back to the interpretive hands.
[00:36:25] Alexey Melnikov: John. You'll get you. That's there. Is that gonna work?
[00:36:35] Speaker 4: Fantastic. I mean It works. It works.
[00:36:37] Alexey Melnikov: Well, it sort of works.
[00:36:39] Arnt Gulbrandsen: Right. Cool. I'll move the mic to where I am instead.
[00:36:49] Alexey Melnikov: The correct slides were uploaded, but for some reason, the data track or the Meetecho has not uploaded them. Probably the network problems out there.
[00:36:55] Arnt Gulbrandsen: Right. So this is not about both slides. It's about one of them in order to focus simply. Go to the next one or yeah. Well, you have to scroll down.
[00:37:06] Alexey Melnikov: You can put that down.
[00:37:10] Arnt Gulbrandsen: It's my yeah. I'll have something else in my hand. Right. Interoperable addresses, which is the one I'm not discussing, is for provisioning. It's for non IATF use. There are a lot of users of email addresses, and we have problems today. I have problems today. Every so often, I need to answer what is the length limit for an email address. How long can the local part be? I'd like to have a better definition of email address for humans, for Unicode addresses than we more consensus than we have for ASCII addresses where length limits are anywhere from 30 to hundreds of characters. But I want to put that one off until I've settled the other one. Scroll through there. The syntax document is where I want to actually change the rules. Right now, the local part of a document, the local part of an email address can be any UTF-eight string, which creates some fascinating problems when a renderer uses UTF-eight has nice font rendering, but isn't properly tested. And I can show you some some addresses that render in in surprising ways. So I wrote this document that is strict enough to avoid security problems. If an address passes this syntax, then it's then even simplistic rendering will be safe. It will not show something that confuses people or confuses software. It's also simple to implement and fairly permissive. It permits a lot of addresses that nobody would ever want to use. You cannot have smileys in domains. I don't see a problem with having smileys in local parts, so just permitted. Permissive by default, it just blocks security problems. And I consider user if you can confuse users, then I think it is a security problem at least potentially. Next. We've been through this in various shapes a few times. The current draft is rewritten to update sixty five thirty two, which is one of the EAI documents. I think it contains what should have been in 6532. People were out of energy, and the editor, well, wrote something simple. It doesn't change the ABNF, but it does add rules. Basically, what kind of code points can go together in a local patch. There's some text in there that can be dropped. Most important parts are terms that I define but no longer use, might pull back. Please be forgiving about that. Next. The big question about this is what should it be? Is the six six five thirty two update with rules, but no additional a, b, and f. Acceptable. Anyone who wants to see motivation for having rules can see something afterwards. I'm not going to show that on camera. But on the other hand, these rules cannot be expressed as ABNF. I there are a couple of Unicode code points that should never be in email addresses, but you can't express that as a b n f. Well Okay. Text common
[00:41:53] Speaker 8: is fine.
[00:41:55] Arnt Gulbrandsen: Well, in that case, that's what I have. If we can settle that, then it will be easy for me to to check the syntax. There's implication there that this document should permit everything that is in u a x 31, which is a Unicode document for identifiers, should match such things as variable names, display names on websites, blah blah blah blah blah. And it should also accept everything that's in IDNA 2,008. That needs checking. Should be okay. Needs to be done. If something is rejected here that's accepted in one of those others, that would be a bug in some way. I don't think there is one. I also do have some lack of clarity about one particular code point, which may not be an issue at all. I'm not sure. That one code point I still am in some doubt whether it's I think it's denied by, so therefore, it's okay here. If I check all code points, then I'll check that
[00:43:21] Daniel Kahn Gillmor: as well.
[00:43:23] Arnt Gulbrandsen: So opinions about doing this as an update to 6532? Anyone?
[00:43:31] Alexey Melnikov: Thumbs up over here.
[00:43:32] Arnt Gulbrandsen: Is in favor. I'm glad
[00:43:33] Alexey Melnikov: Thumbs up over here.
[00:43:35] Arnt Gulbrandsen: Are you happy with this particular update to sixty five thirty two, which contains must but does not contain any ABNF?
[00:43:49] Barry Leiba: I'm curious if John John Clemson has any thoughts on this. You
[00:43:55] Alexey Melnikov: have one more slide, by
[00:43:56] Speaker 8: the way.
[00:43:56] Arnt Gulbrandsen: I'm also curious about what John
[00:44:01] John Klensin: I have not had time study the latest draft. I've been spending too much time being obsessed with the, document, which will not be mentioned. But I will try to look at it sometime soon.
[00:44:17] Alexey Melnikov: Pictures in the queue.
[00:44:19] Arnt Gulbrandsen: John, question. Are you in principle happy with, having new rules but no new ABNF?
[00:44:28] John Klensin: Yeah. I I don't think in this particular case, ABNF is especially helpful. I am I am concerned, but, again, I've not reviewed the document about the UAX 31 Precinct, I D A 2008 Intersection. But, again, I'll have to study that carefully.
[00:44:55] Arnt Gulbrandsen: Well, that intersection is not a standards matter, but if the unexpected differences would in would or might indicate bugs in one of the two documents. See what I mean?
[00:45:15] John Klensin: Oh, I I understand what you mean, and I think that and I think that's right. But, but I'm a little concerned that, and I think the principle that if if these three documents disagree, that warning about that is a good thing because that's ultimately at the core of what you're asked for after. But, again, I I'm gonna need to look at it carefully.
[00:45:42] Arnt Gulbrandsen: Cool. Thanks,
[00:45:43] Alexey Melnikov: Bron Gondwana. Bron Gondwana.
[00:45:44] Daniel Kahn Gillmor: Bron Gondwana, go ahead. Yes.
[00:45:46] Bron Gondwana: Since we're talking about 6532, one of my major beefs with it is section 3.7 specifying message slash global, which is a profound and deep mistake in, changing the semantics of mine. And I'm wondering when, if ever, we we might get around to fixing that problem, which is allowing the super encoding, of, you know, multipart objects such as message is really a bad idea.
[00:46:25] Arnt Gulbrandsen: Should I answer? Mhmm. Okay. I've I've implemented some of the code that actually uses message global, and it feels it felt like a mistake. It felt like words on top of words. I agree that changing message global would be a good idea. I'm not sure to what.
[00:46:59] Bron Gondwana: To just send as is. Or even better, if that's the situation you face, return message headers as a text object, which can be encoded.
[00:47:11] Arnt Gulbrandsen: Yes. Alright.
[00:47:13] Bron Gondwana: We have good choices. Pick one. But message global encoded in a non identity transfer encoding is a disaster. Shouldn't have happened. You might recall Ned Frieden some some years back in the discussion agreeing, but, you know, we still haven't fixed it yet. It would be nice.
[00:47:35] Arnt Gulbrandsen: Are you suggesting to fix this in the same document?
[00:47:40] Bron Gondwana: I don't know. I'm asking.
[00:47:42] Arnt Gulbrandsen: Right. Okay. My personal strong preference is to push this document through soon, and I mean soon, and fix message global later. I'm perfectly willing to work on it. I'll volunteer to write a document, but I would very much like to not do it in the same document and not hold up hold up the SMTPA SMTP UTF-eight syntax documents.
[00:48:21] Bron Gondwana: Sounds fair.
[00:48:24] Barry Leiba: Alexei? I
[00:48:24] Daniel Kahn Gillmor: basically agree.
[00:48:26] Arnt Gulbrandsen: Alexei agrees with me with me, I think. Yes. Alexei agrees with me.
[00:48:34] Barry Leiba: Bron Gondwana, would you be willing to put your, proposal or proposals on the list for people to look at?
[00:48:43] Bron Gondwana: Yes. No no problem.
[00:48:45] Barry Leiba: Thank you. Anything else, Art?
[00:48:53] Alexey Melnikov: There's one more slide.
[00:48:54] Arnt Gulbrandsen: Well, that's not really much to discuss. Well, when I wrote this slide, I was doing an implementation. I have done an implementation now. I have not checked the diffs with UTS 39, which is another document that kind of defines an email address syntax. UTS 39 is about recognizing email addresses and links in running text. So you that's kind of thing that you see in tweets, for example. Now that I have an implementation well, I suggest working group last call as soon as there are two implementations unless somebody protests against this sixty five thirty two update without ABNF. Also, please review. Yes. Good.
[00:50:05] Ben Bucksch: Good. K. Thank you. Next
[00:50:11] Barry Leiba: up is Lisa.
[00:50:13] Alexey Melnikov: I think I have those slides. Yes. You want PP archive.
[00:50:16] Barry Leiba: Correct. There you go. Hello.
[00:50:22] Alexey Melnikov: Thank
[00:50:25] Lisa Dusseault: you. Lisa Dusseault here talking, speaking in part for Hans and Alexei over there in the green shirts.
[00:50:34] Alexey Melnikov: Did you guys coordinate today?
[00:50:39] Lisa Dusseault: This is a, format to, explain how to bring together JSON files. So so when it's not in a protocol message, but in a file to and its contacts or tasks, along with emails, which are in iCalendar format, how to zip them together, and how to give the folder structure so that a user can do a full export of personal data or a partial one and, have a good hope of reconstructing it, importing it to another system, Mappings to protocols for server to server data portability or other communication around sending these this this archive format are are TBD, certainly something I plan to work on when the time comes. There we go. So this is the and anybody who knows all the stuff I'm working on will not be at all surprised to see a lot of JSON schema in, the latest version of PDP Archive because, I I I don't like working on examples and not being sure if they're correct. So I wrote the JSON schemas for all of the examples in the document. They end up being hugely overlapping with what's defined in the various other RFCs, like, for JMAP and JS calendar and things like that. So there there's a possibility for them to be very duplicative of other standards. And and and there's there's there's some nice things you can do to define the fields that even come out of IMAP and tightly constrain those. So that's just like the header of one of these JSON schema schemas that live together as a family. Oh, and by the way, if y'all are doing something similar or with other things besides JS Schema where you have examples and something that the examples have to be validated against or could be validated against, There's amazing support now in, the markdown formats for our, Internet drafts that let you externalize the examples and the schemas and then run CICD to validate them against each other every time you update the examples of the schemas, which I love as it saves me from stupid errors. So recommend, take a look at my GitHub, if you wanna see this in action and the validate script gets run by CICD. What I already said. Yeah. I don't know if these are despite all the work, the which I'm still glad I did because now I know that the examples are valid. I'm not sure if these schemas should live in this document. I'm open to input about that. If we keep them in this document, they could eventually be updated or overruled by future versions of JS calendar or things like that that are that that are adding things to the, the data format, rather than how they fit into the archive format. Like like, love love for people to start thinking about the future of that at some point. JSON schemes are very composable. I could have, if a JSON schema already existed for JS Calendar, have said, this schema references JS Calendar schema and adds one more field.
[00:54:02] Neil Jenkins: Yeah. Isn't
[00:54:06] Ben Bucksch: JS calendar about to be published? Could it be added now?
[00:54:09] Lisa Dusseault: Absolutely. Happy to move this stuff out of PDP Archive into more specific, RFCs that that have more ownership over what's in those containers.
[00:54:21] Barry Leiba: Yeah. DKG, thoughts on the schema?
[00:54:26] Daniel Kahn Gillmor: If it's not gonna be put in JS calendar, I definitely think it should live in this document. So, I mean, I'm I'm a big fan of actually publishing the schemas. I think it's really great that you've done that. And I I wouldn't wait. Put it in the like, keep it in the document. Put it in appendix so it's easy to extract and reference. And, you know, you can nudge the JS calendar folks, but I don't know whether I mean, some of them are in this room right now. But if they're not receptive to it, that's okay. Just let's get it published somewhere.
[00:55:00] Aaron Parecki: Robert.
[00:55:00] Robert Stepanek: Robert Stepanek, JS calendar co author together with me. Yeah. I'm I'm very interested in that. I'm gonna have a look at the schema, and I would like to follow-up then where to put this. But in any case, it's great. We have been hearing about people wanting JSON schemas for that for quite a couple of features already.
[00:55:20] Alexey Melnikov: Thank you. It's like an ad for your other working group. I know.
[00:55:26] Lisa Dusseault: Other amount of work in the last version is on tombs tombstones for deleted folders. I had two general ideas and back and forth on them. I I don't know which idea is better. So I was I threw a couple advantages, disadvantages in here. I was thinking today about, oh, when a user downloads a whole export of their stuff and expands the ZIP file, they cannot they can look at anybody with a, you know, an AI agent or a modicum of of understanding of data structures can look at their folders opening up as they expand this export. And then with the approach taken, they will see deleted folders as folders. So that's another disadvantage on the on the on the cons side of that. But I still think that the way in the draft is a fine way forward, but I'm open to changing it if consensus shifts on that. I just haven't heard a lot of consensus, just some helpful input from Ken. Like, the the ability to be clear about deleted messages and message flag flag data is a benefit to the current approach where the fold the deleted folder does exist in an incremental update. It just says inside its metadata that it's been deleted and when. And, oh, and and one thing to point out, if a user does they won't even be bothered by this. In a full export, that's not an incremental export. Why would you include deleted folders? The spec says don't.
[00:56:57] John Klensin: It's you. It's you. Sorry. I got confused by the number two. I thought I'm second on the list. So this is Hans Joerg. Just adding adding to that. So I'm I'm also don't have yet a final opinion, which is why this is still open to a certain extent. Just adding to that, I also know of systems where literally folders are not just deleted but parked in a sort of deleted space where they can be undeleted, so like a soft delete kind of thing. So probably that would also be something for the discussion if this should be allowed to be a you know, a differentiation or different mode of deletion and, you know, how many of these we wanna support in the archive font.
[00:57:40] Barry Leiba: That sounds like an argument to keep it as is as as a as a folder.
[00:57:44] John Klensin: Well, both might exist.
[00:57:45] Speaker 4: Like, moves to something.
[00:57:48] John Klensin: Sure. Yeah. I'm just saying things are complicated. And, I mean, might might make sense. I mean, I'm not even sure we can decide on all these things yet before implementing some of this with some systems to really figure out what makes sense.
[00:58:03] Ben Bucksch: Ben? Folders are hierarchical. Right? Folders are hierarchic Ben Books for. They're hierarchical. Right?
[00:58:14] Robert Stepanek: Yes.
[00:58:15] Ben Bucksch: So can you put the information on the next higher level folder? These are the deleted folders, and then you don't have the problem when you expand something that you don't if expand the ZIP file, you don't have this that folder in there.
[00:58:26] Lisa Dusseault: Absolutely. We cons con I considered that before writing this approach and would be happy to shift to that. It the disadvantage being that then you lose the list of deleted messages and the I mean, I guess you could put that in the metadata of the superior folder. So, yeah, maybe we can have the best of both worlds.
[00:58:48] Speaker 4: Super working. Nothing.
[00:58:53] Lisa Dusseault: Superior. Yes.
[00:58:53] Alexey Melnikov: He's being a light band.
[00:58:56] Ben Bucksch: Alright. D k g?
[00:58:58] Daniel Kahn Gillmor: Yeah. This is Daniel. So I I am not sure you've listed the only disadvantage of the deleted messages showing up. I mean, you're you're concerned about user confusion about, like, well, hey, why is my deleted message showing up? And they have to go in and find it. But, also, people like to delete messages because they want there to be no record of the message that it ever existed. And this is obviously like, I can see how it's helpful with an incremental backup. You wanna, you know, delete scrub the message from whatever archive encounters this thing. And at the same time, there's a real tension there, and I don't exactly know how to solve it. But just moving it to a different location, that might be better to solve the the disadvantage you've identified here, but it doesn't resolve the disadvantage of actually leaving a trace that there was a thing that the person doesn't want to exist anymore. So I don't know how to solve it. I just just flag that there's a different disadvantage.
[00:59:59] Speaker 8: Okay. A little bit of follow-up to DKG, actually. The good thing about this feature, you don't have to use it. As in, like, it's an extra piece of information if you choose to include it. But if you omit it, you know, it's actually you know? And maybe we should talk about it in the document just saying, you know Yeah.
[01:00:17] Ben Bucksch: If you are
[01:00:17] Speaker 8: concerned about leaking information about messages that existed, then don't do that. Maybe.
[01:00:27] Alexey Melnikov: Ben?
[01:00:31] Ben Bucksch: So d k g's react Ben books. D k g's reaction was my my first thought, but it appeased me was that you said it's not included in full backup. This is just the incremental. Right? So if you make an incremental update, I think it's very useful to have the information to know what I want to delete now. So otherwise, I have to discern that from comparing the two, and that's a lot more difficult. And it reminds me of JMAP, where also when I get a sync update, I also get explicitly this thing has been deleted. And I need that. I need this information. Otherwise, I I I cannot securely delete things because I might not have the full picture, etcetera. So I think for an incremental update, it's very important. For a full update, it shouldn't be in there.
[01:01:13] Lisa Dusseault: This is great stuff to add to the spec. Excellent points.
[01:01:18] Alexey Melnikov: Brown. Yeah.
[01:01:22] Bron Gondwana: I was just going to say that you're trying to break the laws of thermodynamics or similar. If you're going to say, both want to delete this without any trace of it, and I want to do incremental backups. You can't do incremental backups and delete the thing that's in the previous backup without replacing the previous backup. So the that that problem is it's not a problem because it's not solvable. It's not a thing.
[01:01:49] Alexey Melnikov: Mario Loffredo.
[01:01:50] Lisa Dusseault: Still worth some security considerations text.
[01:01:53] John Klensin: Yep.
[01:01:53] Daniel Kahn Gillmor: Yep.
[01:01:58] Bron Gondwana: So hey. Mario Loffredo, the general stalwart. That this changed a while since a a bit since the last time I saw the first draft. So I was I wanted to ask why you want to make this like a synchronization format and not just like a Google takeout kind of one for one shot migrations. Mhmm. Because this increases high complexity, and then you need to synchronize also files, calendar, context, emails, and there are a lot of problems around that. So that was the question if you were willing to make it simpler, just a one shot migration tool.
[01:02:36] Lisa Dusseault: Yeah. Absolutely. We considered that. And we did draw a line. We we decided that one way synchronization is actually pretty close to the single export. Whereas two way synchronization where either one can make live changes, that's a lot harder. So that's where we drew the line. And, if if I assume you've read the draft. I don't believe that the one way synchronization features make it that much harder. But the use cases that they support are just so painful today. I, exported a bunch of my contacts from my Apple cloud that came from my phone, and I imported them into Google. And I got all my Apple contacts content copied into my Google mail, whether or not they preexisted. That's fine so far. Then when I tried to do that again later as if I was like going on through life and adding things, every single Apple contact got re added to my Google contacts in that reimport, every single one. And so the small features like having to have a UID so that you know when it's the same thing that was imported before are are really easy to add, but they can have the potential of fixing super painful use cases.
[01:03:52] Bron Gondwana: Okay. Yeah. It was mostly about the deleted folders, keeping track of that. It is okay perfectly if you Yeah. If you're exporting an archive to a new server to deal with us in the initial synchronization and keeping track.
[01:04:06] Lisa Dusseault: And and we need to be clear if we're not already that for an implementation to only do bulk export and not incremental exports is a perfectly good implementation decision.
[01:04:17] Bron Gondwana: Yeah. Yeah. Okay. And the second comment was about the JSContact, vCard, and JSCalendar iCalendar breach that I think that was a comment I left at least on the list some months or years ago. I don't know. That there's, you know, vCard and iCalendar is like a wild west out there. So it's when you use v js calendar, jsContact and jsCalendar as a transport format, in many cases, you cannot go back to vCard easily. That is on the on the RFC that Robert wrote the conversion, and I I implemented the conversion. There are many cases when when you're modifying for some something on on JMAP, then you're breaking it for the vCard and iCalendar client. So that is something that needs to be taken into consideration, I think, because if you have a, like, an old CaldApp server and you're using this archive format as a transport, you will be probably breaking some records by using JS calendar and JS contact as a transport because you cannot go back to the exact original file vCard.
[01:05:29] Lisa Dusseault: I would love to nail down the exact use case you're thinking of because if a server is using the old vCard, how are they importing this export data? Is it a server function that somebody's had to program? In that case, I think they would have to write some code to do some translations and and perhaps move things to x dash v card properties if necessary. If it's a client that's doing that, then what work is the client doing to translate these things?
[01:05:57] Bron Gondwana: I no. What I was saying is that, let's say, that the server, whoever is writing that let's say you want to keep your moving server. Right? And you want to keep Apple Calendar client accessing the same record from in server that was accessing survey a on server b that you're migrating to. So the the the tool converting that to what I'm saying is that the JS calendar representation and JS contact representation cannot represent exactly what you have on vCard on on iCalendar. So by using PDP Archive as a transport format, you're breaking the original in some cases.
[01:06:36] Lisa Dusseault: Some Oh, yeah.
[01:06:37] Bron Gondwana: Cases, you will be breaking that, and some clients might have problems reading that the original vCard or iCal.
[01:06:45] Lisa Dusseault: Absolutely. Let's get into specifics because the things that might break, and there might be things that break, we can we can try to document.
[01:06:52] Bron Gondwana: Okay. I'll make sure to touch it.
[01:06:58] Lisa Dusseault: Feeling,
[01:07:02] Barry Leiba: Okay. Next up is DKG.
[01:07:05] Alexey Melnikov: Is there a deck? There is a deck.
[01:07:07] Barry Leiba: Yes. There is.
[01:07:09] Jim Fenton: Unimprove it. Right? Yes. Here we go.
[01:07:14] Daniel Kahn Gillmor: Try a different control.
[01:07:20] Alexey Melnikov: Slides are yours, Daniel.
[01:07:25] Daniel Kahn Gillmor: Thank you. Hello, everybody. Sorry. I'm outdoors right now because it's I don't wanna wake anybody else up. So this is talk about Unobtrusive Signatures, which is an adopted draft in Mailmate. It's worked by Kai Engert, Andrew Gallagher, and myself. So just a a brief reminder, the goals of this project are to reduce the cost of end to end cryptographic signatures on email so far that the sender shouldn't have to actually weigh any choices about whether to sign the message or not. So in particular, we wanna make sure that the signed mail is readable by a legacy mail user agent. We wanna make sure that there's no or as very little room as possible for recipients to be confused about things like naive recipients using legacy, no user agency. We don't wanna hear like, oh, I can't open your attachment or what's this thing you sent me as part of your message. And in particular, we wanna make sure that implementers that are handling this will treat a broken signature as no worse than no signature at all. So that is, you know, the we want it to be fully unobtrusive, so you can make the signature and not worry that it's gonna cause you a headache in the future as a signer. It may not work. The the signature may not come through unmolested, but it's not gonna make more of a problem for your recipient than an unsigned message. So explicitly, there are some sort well, there's there's some non goals of this draft. One is that we're not trying to make the messages tamper resistant. The goal of digital signatures is to make them tamper evident, and we can't actually make them fully tamper resistant. And we don't think that that's the point of this particular spec. We are explicitly ruling out any use here for encrypted messages. Encrypted messages are great, in my opinion. You should use them. But if you're not, this draft is a thing to consider. And we are definitely not doing any novel cryptographic work. We wanna use existing cryptographic standards. So since last time, we've aligned the message economic utilization with the DKIM simple. That's about as far, I think, as we are willing to go in terms of trying to make the messages, you know, transit smoothly. We expect DKIM simple to be unmolested for the most part in transit, but, of course, there are lots of exceptions which we'll get into a little bit later. We got a report, that there is significant, signature break signature breakage. Unintrusive signatures are broken with the Microsoft Exchange mail transport agent in most cases for most messages. And we'll talk about that in a bit. And we also added an explicit CMS variant so that this works with either CMS or OpenPGP, are the two end to end cryptographic signature standards for mail. Right. So this message normalization line with Deacon Simple. So that was that's just an overview of what we're gonna talk about. So we aligned it with Deacon Simple, and then, basically, we're just saying, you know, apply content transfer encoding to make it seven bit clean. Before before you send before you sign and send, you make it seven bit clean. You avoid multiple blank lines at the end of the message, and you make sure the linings are all CRLF, and then that's the thing you sign. And for the verifier, again, you make sure that it's in CRLF even though it might have been translated into some different line, a new format, and you trim any extra blank lines that should have at the end of the message. And we think that that is, you know, those are reasonable, steps to take. They're not too crazy. People know how to do them. They're universally applicable, and that's about as far as I think we're we're, able to to take the normalization process. That said, even if you follow those rules, one major air transport agent does do some pretty dirty things to these messages. It's not clear that we know how to get the canonicalization clever enough to get it past exchanges willingness to modify it. I mean, it does things like change the line breaks in the basics before kind of transfer encoding. It actually reformats the HTML within a text HTML part. It will strip or modify some internal line part headers. Those are I mean, those are only a few of the various types of breakage that Exchange does, I think, due to its architecture, which has a bunch of, I think, technical debt that it's has not managed to pay down yet. Exchange does have a special carve out for multipart signed messages, and it avoids molesting multipart signed messages. And it's not clear that we can tamper with our specification here to make it fit in the carve out that Exchange made and still keep the uninterested signatures goals intact. Because, basically, the only carve out that they have is for messages that are structured with exactly two parts, one of which is the message signature, and that reintroduces the problem of I can't read your attachment. Art, I see you at the line at the at the mic, and I know you're not, signed in. So if you wanna speak, I would say go ahead.
[01:12:58] Arnt Gulbrandsen: I was considering how to say what I wanted to say. I think the best and most polite way is that I see exchange in the headline there, and I suggest that we proceed to the next slide.
[01:13:16] Daniel Kahn Gillmor: Right. And so this is, I think, actually the observation that we made.
[01:13:20] Arnt Gulbrandsen: Actually, I want to give a reason. Exchange is the MTA that has a lot of users that apply link changes. If you have a if if there's a link in an HTML message, they'll add something like change it to h t p l h t t p s.
[01:13:45] Daniel Kahn Gillmor: That is URL defense. That's the third the third sub bullet here. Yes.
[01:13:49] Arnt Gulbrandsen: All of all of that. So we we don't really have a hope of getting past that. So let's just next slide, please.
[01:13:58] Daniel Kahn Gillmor: Right. So that was the conclusion that we've come to here is that we think that there is the the intersection between the unrestricted signature goals and having intact exchange transport is basically the null set. So if exchange wants to fix this and do a carve out like they've done for for multipart sign, they can do that. And if they don't, then they'll mangle the signature, and our tamper evidence will be tamper evident. That will show up tampering when it goes through those messages. So, yeah, I think Art basically said this slide. Ben, I see you in the queue. Do you wanna speak up?
[01:14:32] Ben Bucksch: Ben Books. As much as I agree emotionally with Art, the the user group which which wants that is exactly the user group which is using exchange. They want signatures. Yes. Business users want signatures. Governments want signatures, and they're using Exchange. So is my my I've only my my question is only, is there anybody in the room which can contact somebody from the Microsoft team? Because they have this carve out that they can make another little hole for this, and somebody maybe has connections. I I heard it takes governments to intervene to make this MTA change, but maybe somebody has some internal connections.
[01:15:16] Daniel Kahn Gillmor: I see my coauthor wants to speak up as well.
[01:15:21] Kai Engert: So Kai Engert here. Thanks to aunt who allowed us to get in contact with with someone from Microsoft who was very friendly and interacted with us. And it seems so that they might have trouble to prioritize such work. So and it seems like it would be very difficult for them to do that. So so my conclusion is that we would have to make a first move and make sure that this is actually significantly used, and then maybe this could convince them that it is important. And for the other things that Ben said regarding that business users do want it, yes. I think Daniel said it said it well when in in in our private conversations when he said, well, it's not replacing the existing signatures, but it's making it possible to have those messages who are today unsigned to, in the future, start getting signatures without harm added. And those users who who would like to have signatures guaranteed signatures, they could continue the established way of the multipart signatures.
[01:16:52] Barry Leiba: In the interest of time, if Pete and Brian could be quick, that'd be great. We we we can take this to the list, really.
[01:16:57] Pete Resnick: This is Pete. I'll be quick. I agree with Kai. If this thing gets significant deployment, then at some point, people are going to start seeing mail clients say, I I know what this thing is, and it's a broken signature. And then they're gonna report to Microsoft tech support and say, it came through your server and and my signature broke. What's going on? And, eventually, that may or may not loop back and cause them to fix their problem. And and until that yeah. Go ahead. I'm sorry.
[01:17:29] Daniel Kahn Gillmor: I I I wanted to to just flag that it's not gonna work exactly the way that you described. I think that there that, yes, a wider deployment of this will increase prioritization for Microsoft to handle it. But I but the, you know, unintrusive signatures explicitly say that if you aren't gonna warn the user about an unsigned message, you shouldn't warn them about a broken signature for an an unintrusive signature. And that's deliberate. So the feedback that they're gonna get is not gonna be from individual users who say, hey. Why am I seeing this flag? Because if they start seeing the flag, people will not wanna sign. Right. Right? So so the feed that it what needs to happen is it needs to work and people can say, oh, look. I'm seeing signatures when I use other tools and other, trans
[01:18:12] Pete Resnick: Why am I not seeing signatures when
[01:18:13] Speaker 8: it comes to you guys?
[01:18:15] Daniel Kahn Gillmor: Exactly. Exactly. So that's so so it's gonna be suddenly different, but I think and I think that's the right I think that's the right way to do it, right, if we can see a wider deployment.
[01:18:25] Bron Gondwana: This is Braun. I hope, fingers crossed, that DKIM two will actually help here because if Microsoft want to implement DKIM two, they're going to have to not mess with the content of the message as it comes through in exactly the same ways or describe what they did. And, hopefully, the pressure of having to describe what they did will make them do less. But Microsoft's gonna take years to do anything. They have a big complex system. They can't just say, oh, yeah. We should do this thing and change their software immediately. So it'll take time.
[01:18:56] Daniel Kahn Gillmor: I think they wanna do it. We just need to give them the incentive.
[01:18:59] Jim Fenton: Mhmm. Hi. Jim Fenton. There's this very old legacy behavior, it was old when we did DKIM, of, mangling lines begin with the word from where he puts in a greater than sign or something like that. Is has that been considered, or is that still is that a nonissue now?
[01:19:20] Barry Leiba: I still see it sometimes.
[01:19:22] Daniel Kahn Gillmor: Yeah. That happens in when in particular handling the inbox format because of the the from header. And I don't think that we should be recommending doing that here because it actually changes the the the message. I mean so, yeah, I I I don't think that we should do that. If you're using inbox format and you wanna, you know, keep that convention up, again, like, I think what conclusion that I'm saying here is basically, I like, if people's transport breaks the signature, then their transport breaks the signature, and we can't actually change that. Right? I mean, some people like to stick the text, this message is external at the top of the message body. That breaks the signature. You know? If you do that, you're not gonna get you're not gonna get signatures passed and and intact through the message. And similarly with the with the inbox changes.
[01:20:15] Jim Fenton: Yeah. I I I don't think you can fix it. I'm just mentioning it in case you wanna document if if it isn't already. Just as a
[01:20:23] Daniel Kahn Gillmor: I, yeah, I think I think we might just lump that under the general heading of, you know, MTAs and might might break the signature. And then the result will be no signature, same as if you didn't sign it in the first place.
[01:20:36] Alexey Melnikov: Okay. Thanks.
[01:20:39] Daniel Kahn Gillmor: So yeah. So let me get back to this. Let's see. Right. So this is that's the conclusion that we have here is, you basically we wanna be no worse than the baseline unsigned message. And if you're a user and your recipient isn't seeing that your message is signed and you really want to, you might switch to obtrusive signatures, the classical multipart signed messages. And, you know, and then you but then you have to pay that cost. But now your choice is between do I send unobtrusive signed or multipart signed instead of do I send unsigned or multipart signed. So we really wanna sort of lift the floor here. So just to move on to the CMS point, I don't wanna overspend the time of the meeting here, but we added a CMS example. We documented it. I think we documented it not quite right because none of the three authors are CMS experts. We got some feedback from Tavy about inaccurate text that we need to address. We really need it would be lovely if somebody here who's into CMS who wants to propose improved text. There's a link in the slides here. It it's in our to our issue tracker. If somebody wants to take a look at that text, if you can't find it in the mailing list archive, we would very much welcome a CMS expert to to jump in and say, hey. No. You know, you you you phrased it wrong here. This is the way to phrase it. And double check the test vectors, make sure that they're doing something reasonable. I think my understanding from what Tavy wrote was that the explanation was wrong, but that the test vectors actually look sensible. So, you know, do as we do, not as we say, but it'd be better if we could say the right thing as well. Or the other alternative, if the working group prefers, is that we drop the CMS from this and we, you know, we leave the extensibility so that it's possible to define CMS in the future spec and just stick with OpenPGP for now. But, you know, if anybody is know, likes CMS and knows more about it than we do, we'd love the collaboration. So Pete, maybe you want to weigh in. Pete, are you offering text? Alexei, are you offering text? Please join us. So yeah. So the implementation status, there's a couple different mail user agents that are starting to parse and render parse and generate these things. We've got two underway. The MML is I don't this is a patch I've pushed for MML to generate this stuff, and it's been lingering for a a while. Kai has done a lot of work in Thunderbird lifting this up, and we've got private reports of at least another implementation underway. So, you know, we should have interoperability visible in the public, which is nice. And so, yeah, we just wanna make sure that, all y'all know that this is happening. We really want more reviews. I appreciate the reviews that have come in so far. Please handle the test vectors. Let us know if you think anything's wrong in the test vectors. And, let us know publicly on the list about your implementation status if you're going to do it. So I think that is what we've got. That's a link to the issue tracker.
[01:23:57] Bron Gondwana: Bron Gondwana? Are these signatures supposed to be things that I can check years later, you know, when a message is sitting in my mailbox for twenty years? Or are these only time signatures that, you know, the MUA should then encode as checked at time of receipt?
[01:24:14] Daniel Kahn Gillmor: That is a great question, and it is not something that we are answering in this draft. It is the same status as multipart signed messages. So I don't think that we as a community have established the answer to that question for multipart sign messages, and we're not gonna establish it for Unobtrusive Signatures either. But I really think that would be a lovely piece of work to do to write down what it means to do this. So to do that kind of thing, we would need things like bundling signatures with the message, which some CMS implementations do and some open PGP implementations do, but they don't always do it and they don't do it in the exact same way because, of course, things are structured differently. But I think that's a separate question, and I don't think we should block this draft on.
[01:24:59] Alexey Melnikov: Right. It
[01:24:59] Bron Gondwana: it overlaps a lot with the question of as to how you obtain keys and what their lifetimes are and, you
[01:25:05] Daniel Kahn Gillmor: know Exactly. Yep. And we have answers for that in both OpenPGP and CMS. Whether people use those answers or not is a separate question. But yeah. That's you know, we it would be a shame to try to fix everything in email and to encryptographic protections for email in this one document.
[01:25:27] Alexey Melnikov: Mhmm. Okay.
[01:25:29] Bron Gondwana: My advice for what it's worth is these are short term signatures valid at time of receipt, and any other promise is unlikely to be true for very long. But, you know
[01:25:38] Daniel Kahn Gillmor: I would love it if
[01:25:39] Alexey Melnikov: you would write a draft
[01:25:40] Daniel Kahn Gillmor: that says this is what end to end, signatures for email, mean and how they should be handled. It would be great to try to get somebody to start writing that down, but not in this draft.
[01:25:55] Barry Leiba: Anything else? Alright. Thanks, Daniel. Only thing left on the agenda is, IMAP ObjectID Bis. Braun, Mario Loffredo, do you have anything to say on that?
[01:26:23] Bron Gondwana: Hi. Yeah. The we we don't have much new to present. We include all the requests that were sent to the list. It's been IMAP ObjectID Bis is already implemented with Cyrus also.
[01:26:36] Alexey Melnikov: Right?
[01:26:36] Bron Gondwana: Yeah. And. And I'm not sure if any clients supporting it yet. There was something else that Matt asked about flags. Right? Mhmm. And I guess we can add that to the to the draft. Or
[01:26:51] Arnt Gulbrandsen: I'll I'll
[01:26:54] Bron Gondwana: This is Bron Gondwana. I'll hop up to this microphone. The the real challenge here is do we expose flags exactly identically between every single copy of an email when there are multiple copies of the same email via IMAP, or do we allow them to have separate flags or not? I think Matt has persuaded me that the correct answer for the future is that all the flags should be exactly the same on every single message, that any flags are exposed by a JMAP, and that we should make our server do that under the JMAP. I guess the the idea behind JMAP is that we make life easy for the clients. That's our philosophy. And so the correct answer should be that the flags are the same for every single message, and we're just gonna have to suck it up and make our server do that and any other server implementation's gonna have to suck it up and make that work as well if they offer messages via IMAP. You can always give every single copy a different email ID via JMAP and have different flags on it if you want to do that. But if you're gonna give them the same email ID, then we can say they have to have the same flags, and that will make everyone happy except for me.
[01:28:02] Speaker 4: And we are okay then. That's. Go
[01:28:10] Barry Leiba: ahead, Arnt.
[01:28:10] Arnt Gulbrandsen: Yep. I did a careful review of it. I really like the document as it stands. In particular, the flag handling seems optimal given the somewhat chaotic landscape of legacy flags. I did find one detail I wanted to change, but I can't remember what it was. It was a detail, anyway. By and large, excellent work.
[01:28:40] Barry Leiba: When you think of it, just take it to the list, please.
[01:28:42] Arnt Gulbrandsen: Mhmm. It was on the interactions. I remember.
[01:28:45] Alexey Melnikov: We haven't done one yet.
[01:28:46] Barry Leiba: We we haven't done one, and I'm wondering, anybody have any plans to implement the client side of this? Because their the response format has changed. So we really can't move forward without someone with a client side.
[01:29:01] Bron Gondwana: I
[01:29:05] Arnt Gulbrandsen: might have spontaneous plans as of this moment.
[01:29:08] Barry Leiba: Okay. Thank you.
[01:29:10] Robert Stepanek: Maybe. But what do you
[01:29:11] Arnt Gulbrandsen: pass over to the next?
[01:29:14] Barry Leiba: Oh, yeah? Challenge accepted.
[01:29:16] Bron Gondwana: We can also ask on the matrix.
[01:29:20] Bron Gondwana: Cool. I will certainly implement a client in the JMAP proxy, which talks to an MAP server and then provides JMAP at the other end because that's a very useful thing to have.
[01:29:31] Barry Leiba: Fair enough. Thanks, Bron. Rick, did you have anything you wanted to say about your draft other than this been refreshed? And
[01:29:38] Ricardo Signes: I mean, I'll make got, like, thirty seconds.
[01:29:40] Alexey Melnikov: Yep. That's all we got.
[01:29:42] Ricardo Signes: Yeah. The other draft that we have is the IMAP extension suggestions, which has basically been parked waiting for IMAP ObjectID Bis. We know that we really want ObjectID in there. ObjectID two makes the promise of ObjectIDs for JMAP interop work. So we're waiting on that. Everything else is done except for a couple typos and maybe two sentences.
[01:30:05] Bron Gondwana: Take us home.
[01:30:05] Barry Leiba: Yep. And if there's no extra business, I think we're done for the day. Thank you, everyone. We'll see you in San Francisco.
[01:30:17] Alexey Melnikov: Good job, Erin.