Session Date/Time: 22 Sep 2026 14:00
[00:00:16] Marc Blanchet: When I authenticate to the data tracker, it says unauthenticated or something that then it let me in. So I don't know if there's kind of a temporary hiccup in the authentication or something.
[00:00:53] Asger Smidt: You're breaking up, Joe.
[00:00:57] Joe Mandel: Oh, thank you. Is this any better?
[00:01:00] Asger Smidt: Much.
[00:01:03] Joe Mandel: Thank you.
[00:01:06] Asger Smidt: But people seem to be joining now. So
[00:01:08] Debra Petta: Should we give it a minute to or two more to see if we get any more? Or
[00:01:18] Joe Mandel: started with the note while this would be possible, Debra. Okay. Alright. All the IETF, you agreed to follow the IETF prop policy covers conduct and anti anti harassment. You have truck property.
[00:01:47] Erik Wramner: Excuse me. The sound is very choppy in my end. Is that just me or is it on your side?
[00:01:53] Asger Smidt: No. It's the same here. Your voice keeps cutting out, Joe.
[00:02:00] Debra Petta: Yeah.
[00:02:03] Joe Mandel: Might be Do
[00:02:06] Debra Petta: you wanna hop out and come back in again?
[00:02:08] Joe Mandel: Alright. Is this any better?
[00:02:10] Debra Petta: Oh, yes.
[00:02:18] Joe Mandel: Okay. Now I don't have audio at all.
[00:02:25] Debra Petta: We can hear you. Can you hear us?
[00:02:39] Marc Blanchet: Marc here. Joe, do you want me to take over? I don't have the slides yet.
[00:02:46] Joe Mandel: You can take over if my, audio is still not great, and I'll, do for you.
[00:02:58] Marc Blanchet: Okay. Let me see. Okay. Trying to get I was opening the notetaker, and now I can't see where is this. Okay. I'll try to so okay. Meeting tips. This is very small on my screen. Give me a sec. Well, yeah, make sure your radio and videos are off. But if you need to speak, make sure they're on. User set state your name. Okay. Next next, Joe. Okay. I'll put this notepad. I already opened it, so please try to use it for, common editing. And next step next slide. So, essentially, Debra will provide us an update on the r the draft, which, actually, the URL is no more, good now. It's now a working group document. But, anyway, please, Debra, unless there's any questions I don't see any. So, Debra, can can you, share your screen and start presenting the the the deck is
[00:04:54] Debra Petta: there. Can would you would someone drive for me so that I can focus on the presentation?
[00:05:03] Joe Mandel: I can do that.
[00:05:04] Debra Petta: Thank you. Okay. Ready to start? Hello, everyone, and thanks for making the time today. This is a short status session on r f c forty one thirty bis. These are the things I wanna get through today. Where the four issues from our last July interim meeting stand? What's changed in the draft since then? Any the new issues that have come up out of those changes. And additionally, I wanna include some time in the agenda to discuss a few topics that have bubbled up over the past week. Next slide, please. So let me start with the four issues from the July interim meeting because all four now have direction which wasn't true when we last met. Issue one was where does the backward compatibility text belong? In the normative section or in the appendix? That question resolves itself once we know how many documents there are and that was answered in issue four. With the two documents split, the backward compatibility text is going to go into the second document. Issue two was capability discovery deciding on well known URIs as opposed to an HTTP GET with a known path. That one is closed. The July discussion leaned toward the well known URIs defined in RFC eight thousand six fifteen and the draft now uses it. Issue three was RFC forty one thirty fallback and how much weak cryptography to spell out. The weak algorithms have been removed from the draft entirely. The fallback guidance itself still needs a home and that home will be the second document. Issue four was the single document or two documents and that was decided in July. It will be two documents. So all four issues now have direction. What is still open is the status of that second document, where it gets published and I will come back to that. Next slide, please. So on July 29, five days after our last meeting, four changes went into the draft. They are all in the git repository if you wanna look at those commits. First, the document now declares RFC4130 is obsolete. Second, every reference to triple DES and SHA-one has been removed and replaced with the modern AES and SHA-two algorithms. Third, the AS2 GET references are gone and have replaced with well known URIs as defined in RFC eighty six fifteen. Fourth is a housekeeping change. Every instance of RFC forty one thirty bis is now RFC4130bis in the IANA consideration section. The first three came directly out of the July discussion. The fourth came from IANA recommendations. Also last week, updates were made to the draft to convert from BNF to ABNF. Some miscellaneous updates were also made and a summary was published to the list and can also be found in the git repository. Next slide, please. This is a new item since July and it comes out of the changes working against each other. The problem is the draft now says it obsoletes rfc4130. It also tells implementers to look at rfc4130 for the legacy algorithm SHA-one and triple des. So we are pointing people at a document we have just declared obsolete for algorithms they still have to interoperate within the field. There are two ways to handle this. Option one, keep the reference and scope it and scope it explicitly as non normative. So at least it's clear that the document is describing history rather than specifying behavior. Option b, move the legacy algorithm material into the second document and drop the reference. Since we are breaking into two documents, we should probably go with option b and drop the reference. Option a still leaves a standards track draft leaning on a document. It obsoletes and that dependency will cause a problem. Moving the text means the standards track draft stands on its own and the legacy material sits where implementers migrating from RFC4130 will actually be looking for it. The wider point is that this reference currently exists because the migration guidance has nowhere to live yet. Fixing that fixes this. Next slide, please. So I want to restate the July decision because the way it was framed on my July slides is not quite the way the session settled it. And I would rather we are all working from the same point of reference. What was decided is a two document split rather than one document. In practice, this means that RFC 4130bis carries the modern protocol on the standard standards track with the modern algorithms and no references to the legacy algorithms. Migration, fallback, and backward compatibility will move into a second document. My July slide described the option as minimal 4,130 bis plus a modern AS2 2.0 which did not obsolete RFC forty one thirty and put it at the base and built the new work alongside it. So that is the opposite of what we settled on. If anyone came into this meeting with that version in mind, this is the correction. What is not settled is the second document status and where it gets published and I have a strong view on that. I believe it needs to be an IETF informational RFC published openly instead of living somewhere on Drummond's website. Here's why that matters to me. Not every AS2 vendor certifies their product with a testing house like Drummond Group and this was the primary reason for the updates that we are proposing to RFC4130. It is to share the learnings obtained by those that test their products for interoperability with those who do not. The value of an RFC is that anyone can pick it up, build an interoperable product without a commercial commercial relationship to with anyone. If migration guidance is part is the part the implementers most need and we publish it anywhere that looks like a vendor document like Drummond, the implementers who need it most are the least likely to use it. That would undercut the whole point of doing this work in the IETF. Next slide, please. So what I I wanna bring some implementer feedback into the room because I have been hearing it privately rather than on the mailing list. Four things I'm hearing consistently. Backward compatibility is a requirement for adoption. It's not a preference. It is a thing that decides whether a vendor ships at all. The second, deployment has to be phased. Trading partners upgrade on their own schedules and no vendor can tell their customer base to switch on a single date. Number three, without fallback, AS two loses new implementations to rest APIs and other alternatives. That's the commercial reality behind the technical requirement. A vendor who cannot sell the new standard will not implement it and a standard nobody implements is not a successful standard. And four, migration guidance has to be openly published and free to implement which is the point of my preview in my previous slide. Additionally, the following comments that were published to the list after these slides were uploaded. I'd like to give some consideration to them. One, there were compression comments from Asger and he suggested limiting compression behavior just to compress and sign for AS2 2.0. We currently allow both compress then sign and sign then compress for backward compatibility. The second, there are comments from Alexey related to updating from RFC thirty seven ninety eight to RFC eighty ninety eight. There was some question previously whether we can update all RFCs or do we need do they need to be retained for backward compatibility? And the third was Alexey's comments related to OWS optional white space around the AS two disposition field parameters. I do believe that optional white space is allowed. But I think a few examples of usage are needed to avoid confusion. Next slide, please. So, the four things think that are needed from this group. One, confirm the second document status and that it is published through the IETF. That's the open question from slide five. Two, confirm how we handle legacy algorithm reference and moving it into the second document. Three, confirm the scope split. What stays in rfc4130bis and what moves across. Four, and this one's a resourcing request rather than a technical decision. Taking out a second document increases the editing mode and I do need a co editor identified to help with this task. I'd rather say this now than commit to a schedule I can't hold. If anyone is interested in helping with this document, please let me know. And I'm happy to take questions and comments at this point. Anyone? Oh, Erik. Hi.
[00:15:11] Erik Wramner: Hi. Erik here. I just want to comment on the compression discussion. Personally, it's not a big deal for me because we usually always compress the inner payload. So so one one solution would work, but we do support both alternatives, and I think it's quite good because it is possible that the signature itself compresses. So if you are sending very small messages, actually compressing the signature and the message rather than just compressing the small message and then still having the big signature would give a smaller payload. So I think the current status quo of that one is is good. I would vote for keeping it as it is.
[00:15:56] Debra Petta: Okay. Russ, you're next.
[00:16:03] Russ Housley: Hi. I'm I'm really, dubious about what Erik just has said. Any signature algorithm that's any good, the signature value will not compress.
[00:16:16] Debra Petta: Most of it though I'm seeing is the the signatures are are MIME mostly MIME encrypted or yeah. We we take a signature and then convert it to MIME, and then that, I think, compresses pretty well if that's what you mean.
[00:16:34] Russ Housley: I think you're saying base 64 encoder.
[00:16:37] Debra Petta: Base 64. Base 64. Yes.
[00:16:39] Russ Housley: Okay. So it's it's it's your the redundancy that's added by the base 64 that's compressed.
[00:16:56] Debra Petta: So I I guess that we we can keep this discussion going on the list. I just wanted to bring it up so that that we do talk about it a little bit more than than we have. And this just bubbled up, I think, early this week, maybe yesterday or yeah. It was yesterday, I think, that that these issues came up, and I really didn't have time to address it. Asger, go ahead.
[00:17:24] Asger Smidt: Yeah. Well, it was Friday. But
[00:17:26] Debra Petta: Friday?
[00:17:26] Asger Smidt: Yeah. I I suppose it's superfluous to give my input because I raised the issue. So you know where I stand. But my post did have another another point, which you haven't mentioned about the encryption indication in the spec. I don't know if you missed it. It was at the bottom.
[00:17:55] Debra Petta: I did see it. I I really didn't understand it. Mostly, I did with the spec Okay. And forgive me for this, is I I took everything that and just ported it over from the original.
[00:18:07] Asger Smidt: So No. I get that. That that is what I would expect you to do. So
[00:18:12] Debra Petta: If if we need to change it, I think we just we need to to figure out how to do that. And and if you have suggestions and and, seriously, if you'd like to help me with this because I'm almost reaching my my my capabilities with with being able to make these changes because some of
[00:18:32] Asger Smidt: it, I
[00:18:32] Debra Petta: really don't understand.
[00:18:34] Asger Smidt: I don't envy you, but but I have no idea the the form of I mean, how this is supposed to look essentially. So
[00:18:45] Debra Petta: If there's somebody who does understand it, unless we I don't know. If anybody has any idea of of how it should look, it's been this way for twenty five plus years now. So if if if we're suggesting a change or maybe put some some text with within it that that kind of explains it a little bit more, if if you're seeing it as something that's confusing, that's fine. But, you know, some of these things that that are are suggestions from you guys, I don't know how to handle. Like, the the optional white space. I'm I don't understand that. I'm not sure if that's putting OWS around things is is gonna make it confusing. I know if if I were a developer and was trying to implement this and I saw OWS around things, I I wouldn't understand what that meant without some examples around it. So so I guess we we just need to to figure out and and and the goal is to make this easy for an implementer to pick up and just understand. If if you're reading it and not understanding that that the encryption at the lower level is confusing, then then by all means, suggest a different way to do it because that's Erik, go ahead.
[00:20:36] Erik Wramner: Hi. Well, I think when we discuss these things, we need to see them because I don't remember exactly how they may look. So perhaps either we should move this specific discussion to e mail or if we could somehow share the email text in the meeting so we can see it. The way I remember it, comment about encryption is just when they have an outline of the structure so that it begins with the encrypted envelope. And then there are things inside. And then there in the end of the content, it says parenthesis encrypted just to to show that this content is encrypted because the envelope outside it can now come encrypts it. So I I think it's pretty clear, but we can certainly rewrite it if if if you like. And I I can do that if Asger doesn't want to do it. Just that specific small part.
[00:21:30] Marc Blanchet: Oh, thank you.
[00:21:34] Debra Petta: Oh, so, yeah, let's let's take this discussion to the the group then, and and we can work on on getting it rewritten to a form that everybody agrees with. Asger, go ahead.
[00:21:51] Asger Smidt: Yeah. Essentially, I just want to encourage people to to use the the mailing list. It it seems to me that people they they they post their viewpoints, but they very rarely respond to the viewpoints of others, making it not so much a discussion as here's something I think. It's I would like more discussion in the mailing list is what I'm trying to say. Of course, don't respond if you don't have anything to say. But if you actually have an opinion on whatever someone says, like for instance, whether there should be more than one way of handling compression, then by all means, respond.
[00:22:50] Debra Petta: Okay. Thank you. Alexey?
[00:22:57] Alexey Melnikov: Yeah. So, switching topics to optional white space because I raised it. Yes. Basically, your example already require it. So without it, your ABNF and zero three is not correct. So I think it should be required. For example, the space after the colon, header field colon is pretty much always there. It doesn't have to be. So maybe you want to show examples both ways. But
[00:23:34] Debra Petta: Can you provide me examples just just so that I have something that because I don't understand this, and I I would prefer that that
[00:23:43] Alexey Melnikov: k.
[00:23:43] Debra Petta: I get it right. So if if you have some examples that you can just post to the list, I can paste them in.
[00:23:50] Alexey Melnikov: But Okay. Fine. Fine. Fine. Fine. That's fine. And with some of that, like, I in my last message, I gave ABNF where optional white space is allowed almost everywhere. This is matches what's in email MDM spec. You don't have to follow this because you already have some other deviations. But if you do, that's the one you use. But I can give you examples for this.
[00:24:21] Debra Petta: Okay. Right. Alright. Thank you. Erik?
[00:24:29] Erik Wramner: Yes. Concerning the white space, I think the MDN fields are following more or less the same rules as HTTP headers. Right? Plus they are in the MDN spec. So think instead of trying to describe how the notation works, we can just say that this looks just like in this other specification, but they do have examples, perhaps HTTP.
[00:24:58] Debra Petta: Okay. Thank you. The the
[00:25:01] Alexey Melnikov: one the only difference is HTTP doesn't allow line header line folding, I think.
[00:25:09] Erik Wramner: Well, it does, actually. Sorry. It does.
[00:25:12] Alexey Melnikov: Okay. At least
[00:25:13] Erik Wramner: the h t p the h1.1 version does.
[00:25:16] Alexey Melnikov: Okay. In this case, there are no differences. That's correct. Yes.
[00:25:23] Erik Wramner: Okay.
[00:25:26] Debra Petta: Does anyone else have any other comments? How does go ahead, Marc.
[00:25:33] Marc Blanchet: Yeah. I was just going to say there's a few comments on the meaningless about compression versus signature and con so that I don't know. I don't want to, you know, ask someone to speak, but I see Russ could probably provide some insight about of that.
[00:25:59] Russ Housley: Well, I put in chat the logic for why the base 64 signature value will not compress well.
[00:26:11] Debra Petta: We're no. We're currently using it. So I'm I'm not sure if why why you don't think it
[00:26:20] Russ Housley: It won't be smaller. It will compress. It just won't be smaller.
[00:26:26] Debra Petta: Okay. Well,
[00:26:29] Erik Wramner: I think, really, it's a bit irrelevant if it becomes smaller or not. It's more about if people think it becomes smaller or not. I mean, this standard has been out for twenty years, and the standard has said that you can either compress and then sign or you can sign and then compress.
[00:26:45] Russ Housley: I I will accept will accept your backward compatibility argument. I
[00:26:50] Erik Wramner: just Okay.
[00:26:51] Russ Housley: Don't accept the other.
[00:26:56] Debra Petta: Okay. Does anyone else have anything? Alright. So there were some other things that we we need to to figure out, and we can I can publish these to the list, and we can talk about it more so that we have a a larger audience? So we're we're saying that we're going to make this the the RFC 4130bis document purely standards track and then put all of the backward compatibility and fallback information within another spec. Would everybody agree that we should make this an informational RFC, the second document and keep it within the IETF? Erik, go ahead.
[00:27:52] Erik Wramner: Well, yes and no. I think it's great. I think an informational document is fine. What I do want is some kind of message in the main RFC that says that products are strongly encouraged to handle legacy systems using that other document, something along those lines. So that it becomes kind of normative that you are supposed to handle old systems.
[00:28:22] Debra Petta: Okay. Does anybody have any comments about what Erik just said? Should we take this as well as to the group so that we can discuss it as a larger group? I don't wanna start working on the second document and and then have to change it again. So if if anybody has any strong feelings either way, please bring them up now or through the group. But, Marc, go ahead.
[00:28:57] Marc Blanchet: So I don't think there's any problem that the first document refers to the second. It just we essentially, the devil's in the details and how it will be written. It cannot be normative because it's it's actually an informational document, but but I'll leave it in for, you know, wordsmitting later, but there's no problem referencing the others.
[00:29:28] Debra Petta: Okay. Thank you. Asger?
[00:29:35] Asger Smidt: I agree essentially with both Erik and Marc. That's it pretty much.
[00:29:43] Debra Petta: Okay. So then then we will move to the second document, include a reference in the first, and and and more or less state that we that we strongly suggest that they they are able to be backward compatible with the other. And I think we we currently do state that. It's just maybe we keep just moving the stuff into a second document. Marc, go ahead.
[00:30:18] Marc Blanchet: I'm sorry. I forgot to remove my end.
[00:30:21] Debra Petta: Oh, okay. Okay. So I I think then we we kind of have have agreement mostly. And then for for resourcing, I know that Eric's help said he'd help with with some of this. Is anyone else interested in in at least providing a little bit of I don't mind being the the editor. It's just that a lot of this is is, again, outside my wheelhouse. And and I'm not the developer in this. I would rather it it be provided by somebody who is actually intending on doing the implementation to make sure that what the implementers see is going to be be what the implementers use. I'd hate to write this and then find out that that it's it's not gonna be used by our implementers. Marc, go ahead again.
[00:31:27] Marc Blanchet: Yeah. Trying to incentivize people. So I guess you're talking about the second document, which is the migration compatibility, you know, backward compatibility stuff. So this is a call for the current implementations. If you want to have the spec that you could actually implement and use for the this important topic that has been described or discussed since the very beginning of this working group, then the best way to ensure that you will be able to implement is to actually write a spec. So this is another incentive or call for people to contribute for the second document.
[00:32:17] Debra Petta: And even if you you provide it to me in in a rough form, then I can I can get
[00:32:22] Alexey Melnikov: it
[00:32:23] Debra Petta: formatted? I guess, would that also be I'm not sure how to how to get a second document started as well because what I had done and I think Orie helped me get the first one converted over. So just having somebody help me get a second one going would would help us as well, somebody who's who's written specs before. Asger, go ahead.
[00:32:55] Asger Smidt: Yeah. Just thinking aloud here. But if the second document is all about backwards compatibility, isn't it mostly just going to be saying see the other spec? I mean, the original one, forty one thirty.
[00:33:13] Debra Petta: Right. Now we are talking about obsoleting that spec as well. So is it is it safe to point somebody to a to an obsoleted document within the or or do we just write within this new spec? These are the things that that you would do as you're migrating from the obsoleted to the newer one.
[00:33:46] Asger Smidt: But otherwise, the second document is essentially just going to be an informative copy of the original spec saying this is what it would look like if you were to make your system backwards compatible. But yeah.
[00:34:08] Debra Petta: Right. Okay. Erik, go ahead.
[00:34:12] Erik Wramner: Actually, think the new document will not be just a copy because when we started this work, there were lots of things we wanted to clarify and improve on the original document. And all those things basically need to go into second document because most of them have to do with the legacy things. So I think this second document will be very important and I do not think it will just be verbatim copy of the existing standard. Personally, I I would love to help with this, but I have health problems that limits the available time I will be able to spend. So I I don't know if I can promise something really. But Whatever time
[00:34:53] Debra Petta: you can provide, I'd I'd appreciate even if it's just an hour or a month or something that
[00:34:59] Erik Wramner: Okay. In that in that case, I I can definitely do that much. So I I can definitely help with it, but I'm not sure if I can how much I can do.
[00:35:08] Debra Petta: Okay. Thank you. Alright. Anyone else have any other comments or questions or concerns? Alright. So unless anybody else has anything, then this is probably it. We we can we'll get a a recording of this to the to the e list and and and hopefully continue this conversation on the e list so that we're so that it everybody within the community is able to discuss and move forward with this.
[00:36:14] Marc Blanchet: Yep. Okay. Anybody else has any comment or questions before we close the meeting? One, two. Okay. That was a very useful and efficient meeting, so congratulations to everybody. And I think we have a well way forward. So thank you very much for attending, and see you. We as we have discussed over time, we most likely going to have another interim meeting in a month time frame or something like that at the same cadence we we did, but, obviously, with when there's a proper content to discuss.
[00:37:04] Debra Petta: Is there an IETF, the 121 in November?
[00:37:08] Marc Blanchet: Yes. It is in San Francisco.
[00:37:11] Debra Petta: Okay. Will we be having a meeting during that one, or will it be before this or after?
[00:37:20] Marc Blanchet: That's a good question. Well, it's up to the working group to decide. It's got a two months before, so it depends on, you know, if we have you know, it depends on on the editors, actually, if they have sufficient work to discuss. Maybe we we could we could see as we go.
[00:37:42] Debra Petta: Okay.
[00:37:42] Marc Blanchet: I I guess the what we could do as chairs is to actually reserve or ask for a meeting time for San Francisco, the official ITF week, And and then depending on if there's additional sufficient additional, you know, work that requires discussion, then we can have an interim in between that might be the right way to do this. Any comment or from the participants? Well, I guess we'll do that. And then depending on the progress, we'll we'll call for an interim meeting on that. Thank you very much for attending. See you next time.
[00:38:34] Erik Wramner: Thank you.
[00:38:36] Debra Petta: Thank you.
[00:38:37] Asger Smidt: Thank you. Bye.