**Session Date/Time:** 24 Jul 2026 14:00

[00:00:48] **Chairperson**: Alright. Welcome, EDIINT, IETF one twenty six. This session is being recorded. Here's the note well. It covers the IETF processes and policies. By being here, you agree to them. Meeting tips. Please sign in to MeetEcho if you're in person. And then for remote participants, please make sure your audio and video are off unless you're presenting. And if you can, please use a headset. Also, before you get in the queue or when you're in the queue, please state your name. Here are some resources. We have the agenda, notepad, MeetEcho session. And if you need technical assistance, there's a link there too. Here's our agenda. So we just covered the chair slides, being the agenda in Note Well. And then we have Deborah presenting, RFC 4130bis. Any questions? Alright. Deborah, I'm gonna switch to your slides, and you could get started.

[00:02:08] **Deborah**: Okay. Thanks. Did you want will will I have the ability to to click through the slides, or do you want, would somebody else do it for me? Or

[00:02:19] **Chairperson**: I can do it. Can do it for you.

[00:02:21] **Deborah**: Okay. Thanks. That makes it easier. And I'll just keep saying next slide when we're ready.

[00:02:26] **Chairperson**: Okay. Great.

[00:02:28] **Deborah**: Okay. Should I get started?

[00:02:32] **Chairperson**: Yes, please.

[00:02:32] **Deborah**: Alright. Okay. Welcome everyone. After our previous online group meeting, I think last month, was it, like, June 1, we we had a lively online group discussion that still requires some consensus from some of the things after the meeting. So I've compiled those discussion points and have organized them by issue to help us identify where we have alignment and what decisions still need group input. Core But issues center on how to modernize the specification while maintaining interoperability with RFC 4,130 legacy systems. Next slide, please. So these are the four major issues that have emerged from our discussions. In the following slides, I'll walk through each one presenting the points and counterpoints so we can see where consensus is forming and what still needs working group decision. Next slide, please. So the group this the first one centers around backward compatibility placement. The group is split on whether backward compatibility should be normative or non normative. Point a argues that breaking changes are unacceptable in a BIS specification and implementations need clear rules. Point b counters that the specification should define the modern protocol cleanly with legacy support as a separate concern. This decision affects how we handle RFC 4,130 interoperability throughout document. Next slide, please. The second issue refers to AS two compatibility discovery mechanisms. To be able to define how AS two messages are exchanged, trading partners need to discover each other's capabilities whether it's performed out of band or by some automated mechanism. For automation, the working group discussed two approaches. The first is well known URIs with a well known AS two endpoint and those are gaining more support because they're standardized and self documenting. The second is the GET method. It's simpler but requires careful definition and specification. Next slide. So issue three, regards the r f c forty one thirty fallback strategy. Implementations upgrading to forty one thirty bis, that is the a s two modernization specification, will encounter RFC 4,130 legacy systems. We need to specify how systems will fall back but there is disagreement on whether it should be normative or non normative. Point a argues we need clear normative rules. Point B says legacy support is secondary to the protocol specification. Based on the discussions we had, the emerging consensus was to allow normative fallback but avoid referring to any weak cryptographic details. Next slide. So on the key decision points for the group, in summary, are four four decisions the working group still needs to make. The first three are closely related. How we handle backward compatibility affects our approach to discovery and fallback. The fourth is structural choice. Do we keep everything in one document or do we split it? Next step. Next slide, please. So so the next steps then summary document I previously provided to the working group on June 24 provides the full context for each issue. We can continue to discuss this on the mailing list or at the next working group session. Once we reach agreement on these four decision points, we'll have a clear direction for updating the draft. Some of the things that that were previously discussed was whether we want to include backward compatibility within the document itself or keep it as a an appendix. Previously, I think initially, it was an appendix and then we moved it within the document itself. And now there's discussion about moving it back into the appendix. That's one of the the big things. And then I think some of the other things are taking out any references to the old or the original weak cryptographic triple Daz, SHA one, and those types of things. So before we start making changes to the document, we really I need a direction as to where to go with this. So that's that's basically everything that I had in my presentation today. Can we have discussion here, or do we want to take this to the e list and continue discussion there?

[00:08:15] **Chairperson**: So you have somebody in the queue.

[00:08:16] **Deborah**: Andy, go ahead. I'm sorry. I I I might have just if you had

[00:08:22] **Andy**: Quite alright. I was waiting for the chairs to actually respond to your question. The but I'll respond on the AD. The so first off, we we don't vote. We reach consensus, and everything has to be confirmed on the mailing list anyway. So anything we say here still has to be put onto the mailing list. The can we back up to the first slide? K. Yeah. This one. Right? No. Next slide. The one about the there we go. I personally don't care. I'm going to tell you that point b, a get with a very fixed path, is going to get a flag raised by the HTTP directorate. So if it's a relative path, that's fine. But it's a fixed path. They're they're going to push back on you. I would think that well known URIs are fairly well supported these days, and so it's probably a good way to go.

[00:09:30] **Chairperson**: Okay.

[00:09:31] **Andy**: And for the record, Alexei, who's in the room, is shaking his head. And Ori is in the room. He's shaking his head too. So there we go.

[00:09:39] **Deborah**: Shaking head yes or shaking head no?

[00:09:41] **Alexei**: Shaking head yes.

[00:09:42] **Andy**: Ori is finally just agreeing.

[00:09:43] **Deborah**: Okay. Agreeing. Yes.

[00:09:46] **Andy**: Yes. Yeah. So let's go to the to the next slide. Okay. So and I think this is this is not this is just me, but the so as an individual, not an AD. But I think there's a bit of what I can tell is, like, frustration with how this is how this is going to work. We don't have to actually say 40 RFC 4130 is bad. Don't ever use it again. There's nothing in our charter that says we have to say that as far as I can I can tell, or it may may may disagree with me since he wrote the charter? But the the so we can put a new document out there that says, this is how you do a s two on on the modern Internet. That's what an applicability statement is. And we don't have to say we're updating or obsoleting RFC forty one thirty. What that means is any client that's RFC forty one thirty compatible or compliant, however you wanna say, yeah, compliant, will just continue operating as it does today. Alright? Anything that does the new a s two, modern a s two, will then, find the well known because it's programmed to do that and be able to use that specification. If it does not find the well known, it can fall back to the RFC 4130. So I don't think we need to we need to, get hung up on that type of compatibility, I guess. I do believe it's in the charter that we have an optional draft that we could write or document we could write, which says, here's how you can, like, bridge these two, and that would be non normed if it's an informative document. So I hope that helps.

[00:11:31] **Deborah**: Okay. So but does that address, for new implementations that still need to interoperate with a a forty one thirty legacy system?

[00:11:48] **Andy**: I I I believe so. So an old so so if I have, I'm assuming a client that, that that does forty one thirty, I would then come through come in and change the code to say, first thing I'm gonna do is look for the well known or whatever the discovery mechanism is. You you could do DNS. I don't whatever. The the the, I'm not recommending that, but I definitely have a bias here. But the the whatever that discovery mechanism is, the the the client would say, I'm looking for I'm looking using that discovery mechanism for the new stuff. If it does not find it, it just falls back on its old code paths. If it does find it, then it does all the new stuff. Does that make sense?

[00:12:29] **Deborah**: Sure. So we wouldn't be using a a version identifier or anything to know?

[00:12:37] **Andy**: It that's probably not a bad idea to still do that, but what I'm trying to say is is that you could use completely new HTTP paths and and everything if you need to.

[00:12:48] **Alexei**: So Okay.

[00:12:49] **Andy**: Because because and the reason we say it's probably a good idea to put the versioning in the new stuff as well is because at some point in the future, twenty years from now, I don't know when, your your kids are gonna come to the IETF, and they're gonna ask us to update this again. And so we may use that as a mechanism for getting a versioned.

[00:13:08] **Mark**: And also because it's a blob. Right? So it could move to different places.

[00:13:13] **Andy**: And and it is not putting versioning information is also one of those things that the HTTP director and the RDART reviewers were probably braced as well.

[00:13:23] **Deborah**: Okay. Thank you.

[00:13:28] **Ori Finkelman**: Alright. Ori Finkelman, can you go forward to the slide that sort of summarizes each of the it's like all of the yeah. This one. So, I mean, my preference for the first one is, like, try to avoid putting important information in the appendix generally. But for backward compatibility, if you're talking about putting this in a protocol document, like, my recommendation is just focus this new document on, you know, only the new bits that you need to define for the new pieces like what Andy was saying and use the Charter's delivery to kinda split out separate guidance on compatibility or migration into a separate document. Because, you know, the more you put in one document, the more mixed mission you have in that one document, the harder the review process is. So I'm a really big fan of documents that do, like, one thing really well and that don't have big appendixes with a bunch of stuff in them. So I would say try to move this guidance around compatibility out of the protocol document if you can get away with doing that. Definitely, use the well known. Don't do anything else. And then the normative rules for minimal crypt weak crypto, I think this is sort of solved if you defer this backward compatibility fallback discussion to a separate document. Just talk about the new strong crypto and the new strong protocol and then, like, leave that tougher discussion around how to do fallback to this other document, and that would be you know, I I don't know if you're gonna be able to get away with that because there there could be, you know, security issues with not getting into the details around point three, but having that while trying to also get the new stuff in seems tough, so I would try and split it out. And then the fourth document structure yeah. I mean, I think this is sort of what I've been saying, you know, now, like, use the fact that your charter gives you some flexibility in terms of documents to make each document kind of focused on one part of the problem space so you don't have them fighting with each other. That's my advice as just a guy on the Internet these days.

[00:15:26] **Deborah**: Okay.

[00:15:37] **Chairperson**: Yeah.

[00:15:42] **Deborah**: Next, Mark. Did you do you have something that you wanted to share?

[00:15:47] **Mark**: Plus one with the last two speakers. Single document only. Go ahead. Single document only, the new protocol. Currently, we have in the document sentences that says should not use triple des. I don't think it will go through ISC.

[00:16:20] **Alexei**: Yeah. Alexei, I think I I'm agreeing. And I was just making observation that, potentially, you might have three documents if you're asking, like, in the fourth question, the minimal base and the modern and then the backward compatibility. But, actually, I would suggest that if you follow advice from Andy, then you just cons you you come you don't have to split the minimal BIS and the modern AS two, and just do it in the same document, and then have possibly a separate document later about backward compatibility if you get to

[00:16:59] **Deborah**: it. Okay. Does anybody else have any other comments?

[00:17:13] **Alexei**: I have new issues to bring up.

[00:17:18] **Mark**: Are we done with that discussion at this? Can you ask?

[00:17:22] **Chairperson**: I think we are done with that place. Alexa, do you wanna bring up your new issues?

[00:17:29] **Alexei**: Yeah. My apologies. I haven't joined the mailing list, and and I missed the chat links thing. But just to give you some background, my company actually does SMTP version of this protocol, but I know enough about HTTP to be dangerous. And I also implement SMIME, so a lot of it just sounds familiar. So, anyway, I read the draft and some

[00:18:01] **Ori Steele**: have

[00:18:01] **Alexei**: a few observations. I think it needs a editing pass to update references. I think you've done it somewhat. But, for example, for HTTP one one, you are still referencing 26 something something RFC, which got replaced by three or four new documents, which describe the same version of HTTP one one, but a lot of issues are fixed. There was some similar issue with some MDNs. I think in some in some places, the document is referencing the most recent one. In others, it's kind of still references the old one, and it's not super clear which is which and why. I'm happy to do a pass and just give you the, you know, all the list of all the places where I think it's out of sync and might need having a look.

[00:18:58] **Deborah**: That would help a lot. Yes.

[00:19:00] **Alexei**: So I'll I'll I'll try to do that, and I'll I'll send it to the mailing list.

[00:19:04] **Mark**: And, Deborah, as a as a git, so you could also do PRs and

[00:19:09] **Alexei**: Okay. Whatever. Well, one thing at a time. So the other issue I noticed is because you are doing a Biz document, you're still using BNF. And most modern documents including HTTP one one moved to a b and f, especially because of implicit white space rule, and there is ambiguity where, you know, where these spaces are allowed extra spaces, optional spaces are allowed or not. I would encourage to migrate to ABNF to be explicit and avoid bugs in the future. So the obvious case how detect that you're still using PNF is you have instead of slash, you know, you you have a vertical bar delimiting, you know Mhmm. Alternatives that's kind of a giveaway that it's still the old way specifying stuff. Again, happy to help with this.

[00:20:21] **Deborah**: I would love the help, to be honest with you. What I had done was took the initial the original twenty five year old document and and just edited it. And and I I do apologize, but this is my my first foray into a specification writing. And You

[00:20:40] **Alexei**: don't you don't you don't have to apologize. That's fine. You know?

[00:20:43] **Deborah**: I I don't know.

[00:20:46] **Alexei**: I think that's why it's, it's helpful to have a fly by reviewers even like me who, you know, can just Sure. Find out. So k. That the next issue is it's more of an observation about complexity and various SMIME options in regards to encryption, signing, and compression. An observation that compression can be die done both before and after signing Mhmm. Which creates multiple, you know, things to test and increase complexity. Again, if it's in if it's deployed both ways in real world and you have no way of actually, you know, getting rid of one of them, you're probably stuck with it.

[00:21:41] **Deborah**: Yeah. It looks that way.

[00:21:43] **Alexei**: But I would like, in ideal world, I would encourage to pick one because it makes it easier to test. You have to generate fewer test cases. You know? It's kind of I know that code wise, this might not be a big deal. It's just, you know, in which order you call different, you know, functions, but it it's still the simpler it is that the easiest it is to do interrupt testing, this sort of thing. So and the final thing, I need to dig into this a little bit more. You're referencing the newest AS2 spec, which I co edited. And I think some of your you're actually using ABNF there, which is good. But I think some of ABNF productions might not be quite compliant comp complying with the AS2 spec the way how extensibility was done there. It might not be a problem. I need to think about this, you know, dig into this, and and see if it's really deviating from what's in the AS2 back, then maybe I'll suggest some text pointing this out and saying, you know. Okay. Yeah. Yeah. This this yeah. I'm not sure whether it's an issue yet. It's just it just looked a bit odd. I know it's not a good enough reason. I I just didn't have enough time to to dig into this. That's it for me. Thank you.

[00:23:26] **Deborah**: Thanks.

[00:23:31] **Andy**: Alexey, can I ask that you subscribe to the mailing list? Thank you. I know you're busy. The the one other thing I just wanted to note that that caught me immediately is that the document says it's informational, and I believe it's supposed to be standards track. So we need to make sure that gets fixed at some point. It

[00:24:02] **Mark**: may be before because the Mark here. It may be be because 4130 was informational.

[00:24:14] **Deborah**: Yeah. I think so. It was?

[00:24:16] **Mark**: I yeah. I was involved in with Rick Drummond at that time, and I think there was some pushback in the ISG to be a standard track or something. But I may be wrong.

[00:24:28] **Andy**: You know, those ISG people, you just can't trust them. Yeah. The No point. I'm pretty sure that we that 2026 says applicability statements are standards track. I'm I'm I'd be surprised if they weren't. So, anyway, the the charter says standards track.

[00:24:46] **Chairperson**: Yeah. It doesn't seem

[00:24:48] **Alexei**: maybe it's not.

[00:24:50] **Deborah**: Yeah. That that can be changed if it needs to be.

[00:24:53] **Alexei**: Yeah.

[00:24:58] **Deborah**: We are looking for some some more authors if anybody is willing to step up and help me. This is a big task to do alone. So if if anybody has the time and the the energy, I'd appreciate it to to have somebody to at least bounce ideas off of.

[00:25:28] **Chairperson**: So we could the chairs can try and help get you a coauthor. We'll send out another email to the the list and maybe talk to some people here even though it's the end of the day. But so the queue is cleared. Is there anything else you want to bring up, Deborah, or anybody remote or in the room?

[00:25:56] **Deborah**: So for the next steps, I think we we really I don't see anybody who's been discussing on the e list here today. So Yeah.

[00:26:07] **Mark**: We

[00:26:07] **Deborah**: probably need some sort of email back to the list to just give a summary of what's discussed today or just a link to this recording so that people can sit down and watch it and get an idea of what we discussed today and then what our next steps are. I think that we we probably need to start hacking up the doc again and getting some updates out for people to review.

[00:26:46] **Chairperson**: So I'll send out an email to the list with the recording and the minutes so that everybody can view it. If you wanna send an update as well, that that's more than welcome. Okay. Ask Mark. You can just use this if you want.

[00:27:17] **Mark**: As individual. My recommendation would be a document that only talks about the new protocol. That's it. Start there. Then we'll look into the remaining stuff either somewhere. But if we have a, you know, a concrete, well defined, bounded document that describes, you know, new version version two of this document, then I think it will be even easier to then discuss compatibility, interoperability, and everything because we'll we'll be able to kinda have the two documents, one of near the other and then use so my my personal recommend. I'm repeating myself. But

[00:28:14] **Deborah**: So just as a an FYI, we're we originally what had happened was that that I'm part of Drummond Group, and we have a lot of clients who come to us and say, you know, r f c forty one thirty is really old. And it it's it's missing a lot of things that we have implemented that are not in this document and those who don't participate in interoperability testing with Drummond Group don't get to get to get the information that that we disseminate to our clients. So it would be helpful to be able to update the document to include all the things that we include for our customers so that everybody who implements AS two, whether they participate in drum and group interoperability testing or are just an ordinary vendor who picks up the spec and wants to implement it. One, that they're they they all have the same knowledge base and two, that they're interoperable with each other. That they don't need to go through drum and group interoperability testing to be able to have a product that interoperates with other products out in the world. So so that was my initial marching orders for taking the specification and just updating it to include all of the features. Some of the things that are in it now that weren't weren't originally in it, compression. I have to go look through there and look. But there the reliability and the restart, there's there's been a lot of features that have been added over the last twenty five years. I still think that those should remain in this document, but they they also pertain to 4130. So so that's the question. If we split off and and you're saying new features, those aren't really new features. Those are forty one thirty features. But the No.

[00:30:28] **Mark**: They're not. Yeah.

[00:30:31] **Andy**: This is Andy. No. They're they're new features. They're they're part of the new protocol. So if people want these fancy new things, they'll just do the new protocol. Right?

[00:30:39] **Deborah**: Okay. But they're also part of forty one thirty.

[00:30:42] **Mark**: No.

[00:30:46] **Andy**: Yeah. I mean, if they wanna continue doing RFC forty one thirty, there's no we're not protocol police. We're not gonna go stop them from doing it. Right. But I I'm not I I agree with what Mark said. Let's not discuss the let's not discuss forty one thirty. Let's discuss what we want in a new protocol, including all any bells and whistles we wanna put in there. And, and that way, we don't have to say anything about RFC forty one thirty. That makes sense?

[00:31:13] **Deborah**: Sure. So I guess that forty one thirty then, the only difference would be that it would be the the older cryptographic and then which we will not discuss or maybe just a quick note that says if you if you wanna do that, refer to forty one thirty, and that's it. What what is that what you mean?

[00:31:43] **Mark**: Silent.

[00:31:46] **Andy**: I don't think any document is gonna get through the ITF that says do triple des. So in any way, for

[00:31:53] **Deborah**: for Okay.

[00:31:54] **Andy**: So so that's why I'm saying we just don't even discuss it. Maybe later on in in the in an optional informational, we can we can, you know, talk about, like, how you would bridge it. I don't really know how you would say that. We'd probably, in that document, say, yeah. Forty one thirty says do triple does. That's really insecure. So Yeah. Yeah. You wouldn't have to use normative language in a in an informational document.

[00:32:21] **Deborah**: Okay.

[00:32:21] **Ori Steele**: Alright. Or is still yeah. Just to sort of say, like, for the the the new new document, this this document, it's a standards track document, should describe a normative language, how to accomplish the core requirements that, you know, were met, you know, with a s two, but, you know, with the modern approach to all of those particular protocol building blocks. So you guys you you know, the working group and mailing list have the ability to pick the best way to meet those requirements in this document. Now if it's if there's no reason to break compatibility with the, you know, the older document, you could say, you know, we do it the same way. If there's a good reason to improve, you know, to pick a better, more modern way of doing whatever that, you know, this particular piece is, this working group has the ability to do that in a standard structure document. And so I would just say, like, focus on meeting the requirements and, you know, don't go out of your way to break compatibility, but don't be afraid to improve the the building blocks when you have the right, you know, opportunity for for that particular piece. And definitely don't talk about old broken crypto as being, like, maybe you can do it. Like, that will definitely not go anywhere.

[00:33:33] **Deborah**: Okay.

[00:33:46] **Chairperson**: I think we're done. We're done. I think we're done if nobody has any further comments. I'm not seeing anyone jumping up, so thank you all for your participation. Really appreciate it.

[00:34:07] **Deborah**: Thank you.