Session Date/Time: 08 Apr 2026 01:00
Pete Resnick: All right. See if we have a couple—it better not just be you and me.
Robert Sparks: No, no, it looks like we have at least eight other folks in the room.
Pete Resnick: There we go. Good.
Robert Sparks: So, there's other people here, no cameras.
Pete Resnick: Yes. We’ll show our smiling faces and people can pop into cameras. Hello, Robert.
Brian Carpenter: If you want people to turn on cameras, all you need to do is ask.
Pete Resnick: Well, you know, we need to see how well MeetEcho deals with these multiple video streams going at the same time from different places in the world.
Brian Carpenter: It's 1:00 in the afternoon. It's 1:00 in the afternoon in New Zealand, and this is a wonderful time for meeting for me. This is... well...
Pete Resnick: We had to share the suffering somehow, so...
Brian Carpenter: Hardly agreed.
Pete Resnick: And some people griped.
Brian Carpenter: Well, no doubt. I think the Europeans got the fuzzy end of the lollipop on this particular today, yes.
Martin Dürst: Yeah, my impression was that the people in the Asia-Pacific region usually don't even complain if they are not in the right time zone.
Pete Resnick: Martin, your note was quite appreciated. Oh, look at that sunshine outside of Martin's window. That's very nice.
Robert Sparks: It is definitely dark here.
Pete Resnick: So, it is past the hour. We should probably get rolling here. What I'd like to do, we sent a little note to the list about what our not-so-hidden agenda will be for today. So, we would like to get the Math in RFCs document moving along to completion or something close to that. Brian brought up that we do have an issues list out there and if there are particular issues on that list that people want to speak about, we can. I am in the midst of replying to John’s message on the list. I’m somewhat inclined not to discuss 7997-bis on this call because I think it is for the most part a procedural question and one that should probably go to the RSAB, but if we have time at the end we can entertain some of that discussion. Is there anything else people want in particular to discuss today?
Paul Hoffman: I’ll say that once we get to, you know, future work, I’ve got a little bit that I want to say on what I think would be a popular one, but nothing at the moment.
Robert Sparks: I do want to say remember we're not an IETF group, but Note Well-like procedures do apply. And I think looking at the list of participants, all of you know what Note Well means, so I don't think we need to go through that in detail, but I do think it needs stated at the front.
Pete Resnick: Appreciated. So, who wants to talk to Math in RFCs first? Alexis, is that your baby?
Alexis Rossi: Well, I think we're at a point where we're calling for adoption. I haven't heard any like "no, but I really want this changed" except for Carsten's comment about softening the language in the intro and the abstract. And I read that as editorial, not you know...
Pete Resnick: Right. So, we don't have any like "let’s not adopt" and we haven't seen any like major changes that people think are outstanding. So, I guess it’s up to you to decide, but it seems like the call for adoption is going fine.
Robert Sparks: If anyone has any concerns they’d like to raise now, please do so. Yes, please. Anybody on the call have concerns about adopting this document?
Alexis Rossi: Mark raised his hand.
Pete Resnick: Oh, sorry. Go right ahead, Mark.
Mark Nottingham: Yeah, I don’t have concerns per se, and certainly you know if I put my IAB hat on, I doubt the IAB is going to use this capacity in its RFCs. But I know from past experience that accommodating math in various documentation formats is tricky technically; it raises a lot of issues and it’s hard to handle. And so I’m just wondering—and having not participated in this discussion until now—has as much thought been given to the resources that it's going to require to get this actually operational in the RFC series?
Robert Sparks: Well, we do know that it’s chased a few documents away, not having the ability to handle math. And so, you know, NTPB being the first, right? And so having a way to do it is important to some segments of the community.
Mark Nottingham: I’m just asking, has there been a cost-benefit analysis?
Robert Sparks: Well, what is the benefit of protocols not coming here because they can't do math? Or what’s the cost of... I mean, the two sides of the...
Mark Nottingham: I’m more concerned about cost, yeah. But it’s not... I’m not against it, I’m just asking if the discussion’s been had, that’s all.
Alexis Rossi: Are you talking about the cost to authors, the cost to the RPC? I don’t think I’m following 100% what you’re looking for.
Mark Nottingham: Cost of tool development mostly, I think.
Alexis Rossi: So no, not as far as I'm aware. Jean, Robert, you have any thoughts on this?
Jean Mahoney: We have not... the RPC has not looked at it from an editor resources perspective.
Pete Resnick: How about Robert, have you looked at it from a tools side?
Robert Sparks: From the tooling perspective, we're expecting to reuse existing libraries and just integrate them into our tool chain. If we wander off into something where we're having to invent a math layout language, we've done something horribly wrong.
Pete Resnick: Plus one. Does that give you comfort, Mark, or...
Mark Nottingham: It gives me some level of comfort. Yeah, I guess you know this community has a history of creating very bespoke requirements for its tools and its processes without consideration of how they're actually implemented. So it’s good to hear that's been looked into some. I guess it’s just a question of, you know, we have multiple output formats. Are those libraries available and functional for each of those formats? So forth and so on. But it sounds like it has at least been thought about, so I am somewhat comforted.
Robert Sparks: Yeah, well, so elephant in the room. PDF, HTML, all of these things are fine. These libraries render into text... nothing renders to text. So...
Pete Resnick: Exactly. So, it sounds to me like we let the call for adoption run until a week from tomorrow and assuming no other screaming on the list, we'll adopt it and move to get final edits in as quickly as we can.
Robert Sparks: I would observe that Robert's comment applies to SVG as well as it does to math.
Pete Resnick: Paul.
Paul Hoffman: So, one of the concerns which I’ve heard and that I don’t want to get in the way for the call for adoption but will need to get discussed before finishing is, what if we pick the wrong format? Like we pick one now and it doesn’t work for math in the future or someone comes up with a better one. I really don't want that—because we can start to optimize now and say, oh, they’re going to pick the wrong one. And I think that that should not prevent the adoption. I think it needs to get discussed, and I would prefer that the outcome is that by RFC, you know, 10,500 or 13,000 or whatever, we can change math libraries. Like we have changed some rules in the past slowly over time with experience, and people who say we need to nail this down now, I think are incorrect. And I certainly think that that’s incorrect for anyone who's concerned about adopting the current draft as a fairly reasonable starting point. And I speak as somebody who had math in RFC 3-something-something-something, which was of course text-only.
Pete Resnick: Yeah, I guess I’m not feeling terribly concerned about that, but I’m certainly willing to hear from others. RFCs are updatable. Martin, you had a comment?
Martin Dürst: Yeah, first thing I wanted to say that the authors, well, the work that the authors have to do was also mentioned, but I think we are speaking about a small number of RFCs where math is important. It’s important to those people who use it in those cases where they need it. So with respect to authors, I think it seems to be okay to at least at the start say that you well—that's probably the wrong word—but you dump most of the work on the authors, yeah? If it’s okay if maybe there’s not a complete pipeline that everything works automatically from the start, so maybe you just say, well, for math authors have to provide a text-only version by themselves, yeah? And things like that.
Pete Resnick: Reasonable. Jay?
Jay Daley: So, Carsten's comment on this was interesting and I think it potentially points to the need for a principled discussion for us. Because the way I read it was he was effectively saying for simple math that can be written just with keyboard symbols, you know like carets and this kind of stuff, why can't we just put it inline like that? The problem of course is that there potentially is an accessibility issue of that because it's not using a described math language. I think we need to have that conversation at some point about the principle of accessibility because we are, you know, otherwise we're going to be looking at things and making a tradeoff in each case about accessibility and something else and I'm not really sure we should be making a tradeoff, you know, for what is ease of something. We perhaps should be having a principle around it and following that principle.
Pete Resnick: John, go ahead.
John Klensin: I agree with Jay. And just for the fun of it, we were having a version of exactly the same discussion in the mid-80s or the early half of the 80s about NTP, by coincidence, and forcing that into ASCII before it could be published. And then, and then deciding about the time of RFC 1119 toward the September of '89 according to what I’m looking at, to go ahead and publish in postscript as an alternative to this problem. Arguably what this does is to agree with Paul's comment about this stuff being immutable, but at the same time it makes a strong argument for being as careful and thoughtful and stable about this and decisions about not using this unless it’s pretty necessary if we can avoid it.
Pete Resnick: I have an overall comment about that but Martin, go ahead.
Martin Dürst: Yes, with respect to Carsten’s comment, I think it’s pretty easy to say if somebody wants to write 1 + 1 in an RFC, it’s okay to not use MathML and it’s also pretty clear that that shouldn't produce any accessibility issues. On the other hand, there’s actually a report, a Unicode technical report that tries to take using Unicode characters only and get as far as possible with math, and in some cases it definitely goes too far. So I think it’s worth drawing a line there. And I’ll try to post a link to that report maybe during the meeting and maybe later, so you can see what the other end of the spectrum looks.
Robert Sparks: So Martin, do you think that the Math in RFC document needs to draw that line?
Martin Dürst: I think it probably needs to in some way draw a line, not exactly the line kind of millimeter-wise, but say maybe what the policy is, what the thinking is, so—and that's what we have for the other documents but we always had a little bit of work to do thinking about how we can express this so that it doesn’t preclude things on the technical side or just using common sense there, but that it's also kind of clear that it sets some boundaries to avoid the extremes. Yeah, you know, I think about this in other contexts where I'd make this distinction. The policy should be helping the RPC be able to point to something and say 'this is why we did it' and shouldn't tie their hands, but should also when it comes time to give them an excuse to say 'no, sorry, we can't do that,' gives them the, you know, the ammunition to do so.
Jay Daley: Thanks. I just wanted to go back to something I think Robert said about text renderings. Just to remind people that actually there is a well-known text rendering of math. It's LaTeX math inside markdown. It, you know, it begins with a dollar, it then uses what we ordinarily think of as normal symbols and so, so there is something that we can put into text that is both sufficiently human-readable and machine-readable that it is a definable way of doing these things. And therefore, if we were to say right, math in text needs to be this, then because it's machine-readable, it's then accessible in that type of way. And so it—I think we have a solution to this. It's just our knowledge space that's the biggest issue here. We just need to learn some of these things in order to be able to deliver that.
Pete Resnick: So I put myself in the queue simply to come in because you sort of started there, Jay, and ended there well. This leads to a possible thing for our long-term agenda, which is do we want to write a sort of accessibility policy document? I think in the long term, that document is going to say there's lots of tradeoffs, here's the way we'd like the RPC to lean this way or that way. But it may come out so mushy that it's not worth writing as a policy document and the RPC might just say, you know, the RSWG told us accessibility is an important factor, here's our style guide for accessibility. But I’d be, you know, curious to hear what others think about even the possibility of writing such a document. Jean, go ahead.
Pete Resnick: Muted, Jean.
Jean Mahoney: All right, I will try again. So the RPC has on the to-do list to provide guidance to authors on making their documents accessible and it goes beyond—it will encompass artwork and providing, you know, maybe even tutorials about 'this is how you write descriptions for your artwork.' These are the things we would like to see when you are submitting artwork. And although I think for mathematics, as was described, perhaps LaTeX for text may be a way to make that accessible rather than, you know, doing some sort of alt-text for the for equations to describe in words what the equation says. But we do... we do want to make the RFCs accessible for screen readers, for people with low vision. So we are looking at how to put the mathematics into practice, that’s something we will look at.
Pete Resnick: Cool. Alexis.
Alexis Rossi: From an accessibility perspective, my understanding is that the most important format is the HTML format that shows up on the website. So I am less concerned about the accessibility aspect of the text file, for example. I think it should be readable and usable and great, but I think if we're going to think about writing a statement like that, we should concentrate on having one really well accessible useful format and HTML seems to be the thing that is the standard for that.
Pete Resnick: Other thoughts? Well, it is now in the back of everybody's mind that maybe we need to talk about that and maybe we don’t. Okay. So anything else on the math document? I think we'll wait for any other comments in the next week and then off we go. Let's see what else. Brian, you mentioned our issues list. Was there anything in particular on that list you wanted to bring up?
Brian Carpenter: Well, excuse me, the one that seems to have come alive in the last few days again is AI, which I regard as actually part of the larger topic of author ethics in general. So judging by the mailing lists in the plural, there is interest in that topic. But my real point for today was, you know, we've got these 30 issues or so. We should be either closing some of them or doing something about them. Just having them sitting there is a bit embarrassing, really, since they've been there for years.
Pete Resnick: No, Russ and I—it is time to figure out what's going on. We don't need to use the call time for going through issue by issue. I'm sure there's a bunch we can already close on our, you know, own knowledge.
Robert Sparks: Yeah, I mean, however, if there is one that you're like, 'this one's really bothering me and I wish someone would work on it' or even more, 'if this is really bothering me, I'm willing to help someone work on it.' Which one is that?
Brian Carpenter: I think I've enough said what mine is. I have a draft on author ethics which is 10 years old, so slightly out of date. It doesn't talk about AI for example. I'd be willing to do some work on that, not saying, you know, I regard it as a foregone conclusion that the RSWG will adopt it, but at least to try and frame the issue in 2026 terms.
Pete Resnick: I mean, I think it would be well worth our time and yours if you added to your document a paragraph or two about AI. It does not have to be complete. Point to a few people who have been yelping on it in different arenas to say 'Hey, I'm thinking of bringing this to RSWG' and maybe we get enough voices to say 'Yeah, I'm willing to help Brian out' to adopt it in here.
Brian Carpenter: Yeah, the work I did 10 years ago was specifically aimed at the IETF stream, but so many of the issues would be the same for every document stream that I think that was probably a mistake. But then the RSWG didn't exist, so...
Paul Hoffman: So I will vehemently be against bringing that to the RSWG for the main reason that this working group is about policies for RFC publication, not for entering the various streams. And even though, by the way, I am... I didn't know that this existed and I could be one with strong opinions agreeing with Brian on whatever other mailing list this is on. And just as a work note, I'm losing this debate in my day job, so... but I absolutely believe this does not belong in the RSWG. The RSWG is for RFC publication, not for entry to streams. If we add a stream later or even if a current stream says 'screw that, we want AI documents' and there’s a stream that I will not mention but that could go that way, I believe it's completely inappropriate for this working group to have a policy that says 'if a stream handed us a document, we won't publish it because it didn’t follow this policy.' I think that has to be argued somewhere else and I know there’s not a stream for the RSAB, but I really want to keep us out of anything where one or two streams will disagree with the others. I think that's a waste of everyone's time to try to get consensus here on something like that, even though I absolutely agree that particular topic plus whatever else you had from 10 years ago is a valid thing to have an RFC about.
Pete Resnick: Yeah, I'm not feeling terribly concerned about that, but I'm certainly willing to hear from others. RFCs are updatable. Martin, go ahead.
Jay Daley: Yeah, so a question for Paul. Do you think it's appropriate for this group to define what is an author or what is acceptable to be an author? Because that seems to me the biggest question here about whether or not we accept that AI can be an author.
Paul Hoffman: Yes, I agree that that is the question and no, this group is the wrong group to do that. Each stream is the right group to do that for their stream and if there has to be a cross-RFC agreement—I'm sorry, a cross-stream agreement about who can be an author—that is not an RFC publication in my mind. That's not an RFC publication policy, that's a 'what is allowed to be sent to the RPC' or to the RFC editor policy.
Pete Resnick: So a couple of people jumped into the queue. Well, go ahead Jay, I'm sorry, I didn't mean to cut you off.
Jay Daley: Yeah, sorry. Just one thing, I'm not sure Paul how you couldn't take the argument you're making and apply it to everything in the stream—sorry, in the series and say that everything in the series is stream determined. You know, there has to be in my view a core of things that we say are series specific and that's that.
Paul Hoffman: No, no. I believe we can and have come up with rules for what will a published RFC look like and what will the content be, such as English. What I’m disagreeing with is the idea that this group, as it is constituted and with the consensus rules that we have, is the appropriate place to say 'that stream is not allowed to give us a document that it wants to give us.' I don't think we do... I don't think we do. I think the only like high-level restriction we have at this point—and RSAB still hasn't approved it, but I'm sure they will—is that what comes in has to be in English. I believe that's approximately the only hard requirement we have.
Pete Resnick: Martin, I'll let you jump in. And Martin, you need to unmute.
Martin Dürst: Yeah, I agree with the general sentiment that it's mostly the streams that should decide what material they want to publish, but I also would agree that there is probably somewhere some minimum that... I'm not sure that includes or excludes AI or needs any specific provisions about AI, but there's probably somewhere a minimum that if, well, some streams maybe... well, a stream could decide that they want to publish some gibberish and then would that be appropriate or would we have to say 'well, that’s kind of degrading the quality of RFCs' and so there's some line there. But it's probably, for especially for gibberish, we don't yet have to go there. Another thing is that recently I have seen at least one example of some person who proposed a new technology or a new idea that they want to essentially make into an RFC that very clearly didn't use the real name. It was easier for me to spot than for maybe for others because the name was in German. I think Pete just responded to this person. So that's also for example a question: are things that are very clearly not actual names but just some—whatever you can call them—nicknames on a good day, is that something that we want to allow or not? I think up to now the idea was always that implicitly people use their real name. I'm not sure whether there's anything that was explicitly said about this and yeah, okay.
Pete Resnick: Yeah, I'm wondering the same kinds of things, Martin. Mark, you're up.
Mark Nottingham: Uh, okay. So Paul, I think I understand and agree with your motivations but not your conclusions. You know, it's surely within the purview of this group to help define and shape the semantics of what an RFC is in general, especially the metadata in them. And that includes authorship, and I think that's the point that Jay is trying to make, is that it is beneficial to the series if there is a consistent definition of authorship across it. Now whether we can come to consensus on a definition that has the effects maybe are desirable for people concerned about AI is a different question, but I think it's too narrow of an interpretation to say that we can't define what authorship is, for example. Just like it's too narrow to say that we can't give instructions about interpretation of particular tags in the XML, for example.
Paul Hoffman: So Mark, let me just jump in with... I think you might be right. And again, as I just put in the chat, I'm not saying that I know where this discussion should happen. But let me ask you, do you feel that if we give some normative description of what authorship is and the IAB doesn't particularly like it and sort of squeezes something in through its stream, that what we wrote and what this working group wrote and was instantiated as an RFC should trump the IAB in this stream? Or can we come out with a document that says this is what we would like to see and then step away from the responsibility? Because if so, yeah, we've got a working group and this one is fine. I just don't want us to feel like we get to tell streams what to do.
Mark Nottingham: Well, in some ways I think that maybe goes back to the previous discussion about accessibility. It's one thing to define the structures to allow the expression of math in an accessible way in a document. It's another to require that they be used in every single instance. And I think that's the distinction you're talking about. Okay. So that's a great discussion to have.
Paul Hoffman: So if there’s no other place, clearly this needs to be discussed and maybe it comes here, is my view now. If someone had chimed in and said 'Great, I agree with Paul and it should be discussed here,' which I note that no one has done, then I would be more sanguine to say not in this working group.
Pete Resnick: Sorry, missed my mute button there. John, you're up.
John Klensin: Yeah, I certainly agree in principle with the line that Paul is suggesting drawing, but I think we need to be very careful because a line which says all we care about is the publication issues is also a line which says that in its extreme form, every stream should be responsible for its own dialect of Cramdown and RFC XML, and that would be a pretty good way to drive the RPC crazy if those things get submitted, or to discourage anybody from authorship if at the very last point of handover they’re required to rewrite that in something else. So you know, we've got some fuzzy, very fuzzy boundary issues there that are different from the ones which we discussed last few minutes.
Pete Resnick: No doubt. Martin.
Martin Dürst: Yeah, with respect to these issues that we are not yet completely sure whether they are stream or whether they are RFC issues, I think what one possibility to handle is if we need something like that would be that we kind of write up something, but then rather than using the current process, we make sure that we have much more buy-in. It could be that we have a separate, for example, an IESG statement or something on saying that 'well yes, we agree with that,' and an IAB statement and so on, or it could be that it's done with co-authorship or something like that. Anyway, that we currently have a process to make sure that we get comments on the RFCs we publish as policy, but if there's something, for example, if we would say 'okay, we want to have some agreement on what authors mean,' then it might be an idea that we actually have the IESG and the IAB and so on be much more explicit that they agree with this policy. That's just an idea.
Pete Resnick: I guess my question, Martin, would be, you know, there's a reason we have each of the streams represented on the RSAB so that they can bring this stuff back to each of those groups regularly. I think if we did as a working group note that something's going to be wildly controversial to one or more streams, we would probably send the heads up through that stream representative very quickly, but that is kind of their responsibility, isn't it?
Martin Dürst: Yes, in general, yes. If it's kind of like, 'well, we want to do graphics with SVG' or so, then I think the current process is definitely okay. And I think if, for example, we say 'authors,' okay, that's something that the streams might have a much stronger opinion or actually that's getting into content which is their business. In that case, we might have to stress this much more or use that process much more in a much stronger, maybe more explicit way than what we do now. I mean, that's just an idea I just had at this moment, so it's not nothing baked in any way.
Pete Resnick: No, I appreciate it. Paul, you had a comment.
Paul Hoffman: So Martin's idea that he just had in the moment, I think is much better than mine. Mine was 'not here and I don't know where,' and I think Martin's of 'here with buy-in' is actually more constructive than 'not here, go away.' I would ask that if we do this, that we ask for early buy-in—not, I'm sorry, not early buy-in, early engagement—not just of the stream managers, not just the RSAB people, but we ask them 'get your people on the mailing list,' especially your people who have strong vocal opinions, you know, who might be just as opinionated as Klensin and Hoffman and Nottingham are, you know, to get on the list and help develop the document, not just late buy-in where we then have to wash-rinse-repeat what we thought was complete. I think that's actually reasonable. I mean, I don't want to be part of that discussion even though I have a strong opinion because it will go down many rabbit holes, but it is an important one to have.
Pete Resnick: No, fair enough. And the chairs will take quick note of when someone says 'you know this is going to piss off a lot of people' and go shake the appropriate stream heads to maybe bring it back to their communities.
Paul Hoffman: Piss off means 'please come.'
Pete Resnick: Right. Alexis, go ahead.
Alexis Rossi: So we did do the kind of extra care process when we updated 9280 to 9920. And this was basically an extra step of getting approval from all of the streams—all of the streams, I should say. I think what I'm hearing is trying to pull people in earlier if we think that the streams might have an issue. So if there is something that we want to propose as an update to what we think those procedures are, that would be helpful, or if we have, I don't know, if we have some thoughts about things that went well or poorly in that 9920 approval process. All of that would be, I think, really helpful information for the next time this comes up.
Robert Sparks: So Brian, I think you've accepted an action item. I mean, we've talked about this for 15 minutes, so...
Brian Carpenter: Yeah, yeah. That's right. And I'll probably just use the same draft name again because it's completely neutral, but it would be very different. But yeah, thank you for set action item.
Pete Resnick: Although you might want to change its name to add the '-RSWG' in the appropriate place so that it ends up on our associated documents list.
Brian Carpenter: Yeah, I'll check on naming conventions and what the data tracker really does and yeah, okay.
Pete Resnick: Very good. All right, quick one. If we adopt this, a way to get many more of the folks from the management, not just the manager of the various streams, is we actually have a face-to-face meeting in Vienna. I know that makes scheduling really hard for people and maybe we tack it onto dispatch, but I believe that will... that will get a lot of the right people in the room. And look, we're not going to be done in three months. I believe that that will get a lot of the right people in the room.
Robert Sparks: I was just thinking that dispatch's agenda was packed and it didn't finish.
Pete Resnick: Yeah. Mark, go ahead.
Mark Nottingham: Yeah, another way to do that is to have some representative folks go and talk to the IAB and talk to the IESG in their meetings during the week. It’s a little easier to handle, I think.
Pete Resnick: Always glad to take tag-alongs with us chairs to go talk to other groups of people, so... all right, any other items that are new work items that you think might be coming soon?
Robert Sparks: Actually, before you do that, Brian, is Vienna a timeframe where you'll have a draft?
Brian Carpenter: I'll have a draft. I won't be on a plane, though, that's for sure. So don't... don't count on me going to any meetings.
Robert Sparks: Okay, that's fair, but I mean if you're going, 'Aww, I was thinking for later,' then that's not...
Brian Carpenter: No, no, it doesn't take... it's not going to take that long, to be honest. It's fairly clear to me what I have to do to the existing text.
Robert Sparks: Then we'll turn to Paul.
Paul Hoffman: So I don't know... some working groups do much better than others at dealing with one topic at a time. And I have... I am now chair of a working group which is trying to do that. But if this working group is willing to work on two big attractive nuisance topics at a time, neither of which are... need to be done immediately so they could be done sequentially or three. The two big topics that I think are more directly relevant to this working group is what does 'updates' mean or do we use 'updates' blah blah blah. That is something that comes up again and again and there is plenty of interest, but it... it gets bogged down into lack of leadership and such like that. And then the other one being references to internet drafts.
Robert Sparks: Yeah, but let's not mix them.
Paul Hoffman: No, no. Those two are not the same. But I bring up two topics for which there was a lot of interest and failed consensus, although not in a working group already. And both of those were ones that I actually was co-author in because I thought it could be done and I was wrong in the past. So anyways, just throwing them out here. I believe they both will come to this working group in the next five years. Do you do them now, do you do them later? Totally... I see no rush on either of them. If they weren't finished 10 years ago, they can be another five years.
Robert Sparks: Mirja had a document about updates, it expired. Pete, I'm sure you dropped a note to Mirja and Suresh, they co-authored that document, to say, 'Hey, do you want to bring this up because it seems like one that people want to talk about and this might be a good forum.' I did not hear back from them, but I will continue to poke at that. I think it is a reasonable topic to bring up in this working group.
Paul Hoffman: It was actively discussed in other places and got too heated or wasn't going towards consensus. I had proposed a very different proposal, not just like an edit of theirs, and that got shot down as well, which again is fine. I'm not saying my proposal was good. I'm just saying the charter of this working group absolutely covers each of those topics. But the second one, I think needs discussion with the IAB because, you know, the IAB is who created internet drafts and so we ought to go back... and then through the progression of time, the management of internet drafts got handed to the IESG, so we probably need some kind of discussion with those bodies. The narrow topic I'm discussing is the use of drafts in references in RFCs. Normative or informative? Normative is forbidden currently and informative is allowed. And normative actually we break that rule occasionally when it's needed and so having clarity there is good. The other place where the debate comes up is for IANA and that could be a topic later for IANA-bis or whatever, but I see those as very different topics and we do have one that's explicitly about the RFC series. I don't think we're going to come to easy consensus. I agree with that. But the IANA one, early code points, certainly it happens.
Pete Resnick: Jay, you want to jump in on this?
Jay Daley: Yeah, on about updates actually, not about the IDs one. So I'd like to take a step back a little bit to something that is a big bugbear of mine and that is that we publish documents that we know are wrong and we expect the consumers to assemble the correct document from a series of other things. And there are three key parts to that. One of it is the 'updates' bit, where one document has updated another document. Another one is hard-coded metadata where we say something for example in the metadata at the top, hard-code it is a BCP, and then when it gets obsoleted it still says it's a BCP when it isn't. And then the third one of course is errata, where we've gone through a great process to agree that something is wrong. And to me, that's the biggest issue, is the... is this concept of correctness. What are we actually publishing to people? Why are we intentionally publishing something we know is wrong? That to me is just... that's the big thing I think we should unpick anyway.
Pete Resnick: Three big giant topics. Jean, go ahead and jump in.
Jean Mahoney: Just quickly on references to internet drafts. As was mentioned, you can't have normative references to internet drafts. There sometimes a normative reference will change to an informative reference if that draft is not going to go anywhere. And it has been okay to have an informative reference to an internet draft. So it sounds like this may get wrapped up into the conversations about do drafts ever expire, can and... but the changing... I would see that the conversation would tend towards normative references to internet drafts. But that seems to be more of a stream issue also, like IETF stream would feel very strongly about that. And also tangled up with, you know, 'do these drafts expire?'
Pete Resnick: Alexis.
Alexis Rossi: Going back to what Jay was saying, I think the updates thing, maybe that's a big, big thing to bite off. But some of the other things seem like they're a little more straightforward, like making it so that some pieces of metadata are mutable and not like hard-coded into a document, like the status of something. Or fixing very, like typo-like errata things that are like, 'Oh, we put the wrong letter there' or 'Oh, we forgot a line of this code' and it's very clear it's not a held-for-document update, it's not a 'I have a novel to write about why this paragraph is wrong,' but like you know, kind of a simple switch. So not trying to go towards living documents, kind of a deal, but like can we actually fix that error in the code in an RFC when we know we got it wrong? So those things feel a little more easy to bite off maybe.
Pete Resnick: I, speaking as both chair and person in this community, I think you have a very optimistic view of the world. If only because as soon as you start talking about errata, someone's going to say, 'Well, the whole errata system really needs the overhaul' and off to the races we go. I can see the topic of, you know, changing metadata that shouldn't be printed in the document bringing up both the IETF stream status of the document in the standards track versus obsoletes and updates, which are not part of the standards process, which is why you get stupid things like obsoleted documents that are still full standards. So I think these are all good ideas, but I think we probably need to sketch out what exactly the topics are and how into separate documents we can make them. So if folks want to take that on, that would be delightful. We have about five minutes to go.
Robert Sparks: I just want to say what Pete’s saying is if there's not enough energy to write the first draft, there's not enough energy to close.
Pete Resnick: Yep. Ah, Martin is going to corrupt the minds of youth, so that's always a fine thing. John, is that a new hand or an old hand?
John Klensin: Oh, okay. We weren't sure if you were looking for the mute button or the take my hand down button. In exactly that order.
Pete Resnick: Right. All right, anything else for this evening's festivities or mornings or afternoons as the case may be?
Brian Carpenter: I just wanted to apologize for the shirt I chose. I didn't realize how bad the aliasing would be on video.
Pete Resnick: Your window is tiny enough not to be making me completely bonkers, so...
Brian Carpenter: Okay, then I’ll wear a different shirt next time.
Pete Resnick: Very good. As shirts are still required even though this is not an IETF activity. Very good. Seeing no other business, going once, going twice, you have three and a half minutes of your day given back to you.
Robert Sparks: Thank you all.
Pete Resnick: Chairs will get minutes out soon. Cheers.